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:
| Certainly we could have an algorithm that required the dominator to be
| in OTHER or in THIS, or in EITHER. From your statements, it sounds like
| monotone does EITHER.

That's my current understanding.

|>Err, you my pefer this version:
|>http://aaronbentley.com/pastegraph.cgi?n=130
|>
|>Of course, in this scenario, C is not a dominator, so maybe we're okay.
|>~ If we're certain that shortcuts like this one can never cause old bases
|>to be selected, LCA+DOM may still be a good idea.
|
|
| I think one of our most interesting potentials was to have a weighted
| graph, where each edge was weighted by the size of the changes. It had
| the advantage of making C->E very expensive so unlikely to be chosen.

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.

|>Right.  Both the THIS hunk and the OTHER hunk should differ from BASE,
|>to give the person doing the merge the "opportunity" to resolve the
|>conflict.
|
|
| I think the point is that it should be attempting to select the same
| BASE, if I swap THIS for OTHER.

Oh.  I was thinking about the cris-cross case.

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

iD8DBQFD+b9m0F+nu1YWqI0RAijoAJ47f664mmcdtbiPsiVNOpQuVQCMsgCePgIC
B3DW8bW2r7Cf9XLXCw4miZ0=
=7lwK
-----END PGP SIGNATURE-----