More merge base discussion [was: monotone's LCA+DOM algo for selecting a merge base]

[John A Meinel]

Aaron Bentley wrote:
> Aaron Bentley wrote:
>>> The thing is that if C is at all old, the two lines will have resolved
>>> its conflicts differently, and so they'll conflict on the resolutions.
>>> But I guess that's true no matter what.
>>>
>>> It looks like requiring a dominator means
>>> 1. You don't get criss-cross
>>> 2. You don't get mutual merges.
> 
> Here is a worse case:
> http://aaronbentley.com/pastegraph.cgi?n=136
> 
> In this case, LCA+DOM will pick A, but J would be preferable and F would
> be acceptable.  It seems pretty bad that every time you merge, you shove
> future merge bases back to the common dominator of PARENT+MERGE
> 
> Aaron

Isn't it true that, any time you get this pattern:
http://aaronbentley.com/pastegraph.cgi?n=140

Where we both merge a common revision, then LCA+DOM will pick the
ultimate parent (A).
When you probably want it to pick (J).

I don't know if it is quite as obvious what to do when the ancestries
are longer. But what if we had a shortcut for *immediate* ancestors.

Or maybe we introduce the concept of 'last merged' revisions. So even if
you have this:

http://aaronbentley.com/pastegraph.cgi?n=141

You still have a 'last merged' revisions of B+J for the left side, and
J+D for the right side.

So it wouldn't have to be a dominator if it is present in the
'last-merged' revisions of both sides.

Now, doing this:
http://aaronbentley.com/pastegraph.cgi?n=143

Would mean that we stop picking 'J' and revert back to the only
dominator "A".
But that seems reasonable considering the topology.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060220/36ac27d5/attachment.pgp