Interesting merge optimization

[Martin Pool]

On  8 Dec 2005, John Arbash Meinel <john at arbash-meinel.com> wrote:

> Isn't that what codeville merge does by keeping a numbered state? When a
> line is created it gets the value 1 indicating it exists. When it is
> deleted that is incremented to 2, if it is brought back later it is now
> 3, etc.

Only if they incremented the value by 2 when a line was chosen as a
conflict resolution.  I didn't think they did that but maybe they do.

> Though I guess it doesn't mark the revision that it was revived in
> (though the information is there).
> 
> I guess the other problem is that you would have to know that there was
> a conflict in this region, and it was resolved by selecting this line.
> (Hence the line was actively selected).

Right, so the code that attributes lines when committing would need to
know which regions were conflicted.  One way to do this is to re-run the
merge at commit time, which is like what weave commit does, and observe
where there were conflicts.  Another is to remember in the WorkingTree
the conflicted automerge text at the time the merge is done.

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051209/fc156f64/attachment.pgp