Re: [Monotone-devel] merge weirdness...

[Timothy Brownawell]

On 4/26/05, Richard Levitte - VMS Whacker <address@hidden> wrote:
> In message <address@hidden> on Tue, 26 Apr 2005 23:06:02 +0200 (CEST), 
> Richard Levitte - VMS Whacker <address@hidden> said:
> 
> richard> Funny thing is, 'monotone lca' seems to get it right:
> richard>
> richard>   : ; monotone lca 19342b164e493e3da5de22985e38d9c94a664dcd 
> b34d090b64d6a6c48db0583bc210b448142674d4
> richard>   f188f1efa53fc5e1f7aa1313f5d5af8577a0dac9
> 
> I've now noticed 'monotone lcad', which gives that age old revision as
> an answer:

lcad uses find_common_ancestor_for_merge

>   : ; monotone lcad 19342b164e493e3da5de22985e38d9c94a664dcd 
> b34d090b64d6a6c48db0583bc210b448142674d4
>   cdb64688be75821fe5e8187e8ca815cba25d4e85
> 
> Still, I don't currently understand why it's wandering that far back.

It's looking for a revision that is an ancestor of either of the
revisions, and a "dominator" of the other.

A "dominator" seems to be an ancestor such that it is included in
*all* paths back to the origin. Thus, the dominators of a revision
form a linear history.

> What's the thought behind this behavior?

I suspect it's because one of the revisions being merged will be a
child of *only* the chosen ancestor. This probably makes it easier to
figure out what's changed since then.


Fun Facts:
Before .sqlite3 was merged, the last 3 dominators of net.venge.monotone were
5a0431c88aa54f7a35ce21f38b6373429f5dabc3 on the 25th,
f25ed435689f2a1b92eb3249732690ca32a2a7b1 on the 23rd, and
cdb64688be75821fe5e8187e8ca815cba25d4e85 on the 8th.

After the merge, the last one was cdb... on the 8th.

The most recent dominator of the .cvssync head is
0b2794cf1bb4ac86ff58e1f36096416a1d9421a5 on 2004-05-21


Tim