Longest Common Subsequences code

[John Arbash Meinel]

...

> 
> From what I read of the Hirschberg algorithm it will not do particularly
> well at this, or at least it's not a particular criteria.
> 
> When storing texts however we care much more about size and speed, and
> it doesn't really matter if the diff makes sense to a human.
> 

Except we are storing annotations at that time. Which means 'bzr
annotate" will want the human-friendly forms, so you get:


1234 def original():
1234   a line of code
1234   another line of code
1300
1300 def copy():
1300   a line of code
1300   another line of code

versus:

1234 def original():
1300   a line of code
1300   another line of code
1300
1300 def copy():
1234   a line of code
1234   another line of code

Especially since 'def copy()' might be deleted in future versions. And
then when you look at the annotation, you would see:

1300 "Added the copy function()"

And might wonder "why did adding the copy() function modify original()".

It is arguable about not caching annotations at all. But you can't do
annotation merging without them. Which brings up another point, where
someone modifying the original code *might* merge into the copy() code
if we were using edge-based merging. Because with the wrong diff
algorithm, it would see it as an insert of new lines, rather than an
append of new lines, and I believe the merge algorithm would modify the
lines that moved...

I may be a little wrong about this, and it is mostly a corner case that
doesn't happen often. But I think the human-meaningful diffs actually
are important to both the merge algorithm and the annotation algorithm.
They aren't strictly important to the storage algorithm, though we
utilize storage to assist us with annotations.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061102/866af644/attachment.pgp