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:
> Sounds reasonable to me. It seems perfectly suited for something like
> the 'stat-cache'. Which would just have "revision-id\0distance" one per
> line.
> 
> I don't know what the delimiter should be, especially since I don't know
> what our future revision-id spec is going to be. '\0' is a safe bet that
> we won't ever allow it, but I don't know about any other character.

I think it might be a good idea to escape the entries, to ensure no
future-compatability worries.  Then we could use '=' or ':'.

> I think what actually happened is that I merged you, and resolved all
> the conflicts. And then when I merged you again, it picked Robert as a
> base, and I had to resolve *your* conflicts again, not integration
> conflicts.

Hmm, possibly that makes sense.  But it's fairly surprising when it happens.

I've had some discussion with Monotone's Nathaniel Stone, and he says:
"anything involving dominators is _definitely_ not _optimal_.  All we
claim is that we think it is more _safe_"

He also pointed out that it's pretty easy to detect whether there's a
criss-cross: If you have more than one minimal common ancestor, you have
a criss-cross.  If you have an LCA, you have no criss-cross.

If we can generalize this to detect all criss-crosses, then we can use
the data to filter the results of our existing algorithm, which I think
is still pretty good.

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

iD8DBQFD+x+f0F+nu1YWqI0RAg1FAJ4//pkoTCuXfGX6EyG4ZwsI0oyPNwCeIufw
/PRZktyYBtvzq3JxKizkd4E=
=3fBh
-----END PGP SIGNATURE-----