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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> Aaron Bentley wrote:
> As I understand it, the current algorithm uses the revision which is
> farthest from 'null:' which is inside the ancestry of both sides. Is
> that correct?

Correct.
> If it is, then a reasonable cache would be to just annotate each
> revision with its maximum distance from 'null:'. This is fixed property
> that only changes if ghosts are fleshed out. Which means that a cache is
> perfect for it.

Exactly.


> What we haven't fully investigated, is that it preferentially picks
> long-cuts.
...
> We avoided LCA, because A->C->J cause A to look much closer than it
> really should be. (A shortcut). The problem I was running into was that
> it was picking A because the "C" path went through Robert's integration
> branch, whereas I had just merged the other branch.

As soon as someone merges Robert, they get his distance-from-null: +1,
unless they're already farther than him.  I think I have noticed one
case where it chose Robert due to this long-cut behaviour.

I guess one option would be to give up on using mutually-merged bases,
and require that the base be on the revision-history of one of the
branches.  Most of the time, that won't be too bad.

But yes, I've seen this happen too.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD+glU0F+nu1YWqI0RAvnMAJ9nbj5ls9lz5iE1EWYNITUcS6EAjwCfYskK
3SWI8y7+tvZry6tedv3kK2s=
=QDCA
-----END PGP SIGNATURE-----