Re: [Gnu-arch-users] arch 2.0 and delta compression

[Aaron Bentley]

Jan Hudec wrote:
> On Tue, Jul 12, 2005 at 11:12:14 -0700, Thomas Lord wrote:
> 
>>I'm very skeptical of "the Codeville merge algorithm" for reasons
>>not terribly important here.   Let's stipulate, for the sake
>>of conversation, that it's the greatest thing since toast and,
>>additionally, that it imposes a moral imperative on revctl developers
>>to optimize-for-annotate.
> 
> 
> As far as I understand the Codeville merge algorithm, it is a line-wise
> 3-way merge. 

AIUI, it's line-based, but it's stretching it to call this a 3-way
merge, because the three pieces of data are THIS-text, OTHER-text, and
the history of both branches.

There are now two Codeville algorithms, both described here:
http://lists.zooko.com/pipermail/revctrl/2005-May/000005.html

I was referring to the new "precice merge", which I'll describe below.

Each line is identifiable, and can be given a unique ID.  So the merge
algorithm doesn't need any textual context to do merging.  Any lines
that were created in THIS will appear, unless they were deleted in
OTHER, and vice versa.  It's not a three-way text comparison at all, and
I the behavior is different from diff3 if both branches add the same
text independently (rather than through merging).

> On the other hand, it's better in the case when there is more than one
> most recent common ancestor, which is very rare, so it's not really
> a priority.

It behaves much better in the presence of incomplete merges, i.e.
cherry-picking, and I believe it also handles crossed merges well.
These are both problematic in star-merge, though I expect crossed merges
work better with --three-way.

Aaron