[PATCH] test: merge fails since f153af9580fe

[Matt Mackall]

On Fri, 2009-11-13 at 17:35 +0100, Peter Arrenbrecht wrote:
> # HG changeset patch
> # User Peter Arrenbrecht <peter.arrenbrecht at gmail.com>
> # Date 1258130046 -3600
> # Node ID d29e07675d6377bd14feb579c646bf796cc9b60f
> # Parent  f153af9580fe547e74d2b805f9cc52763ce497e2
> test: merge fails since f153af9580fe

> +echo "==== merge c into d as change y"
> +# Here we newly fail. Both c and d are related to u, but as of
> +# f153af9580fe hg merge chooses change a as the merge ancestor
> +# instead of change u.
[...]
> +@    7 df8f864b9dcd: x [branch d]
> +|\
> +| | o    6 61ecd8ec85ca: w [branch c]
> +| | |\
> +| o---+  5 977f54d8a8f3: v [branch b]
> +| | | |
> +| | | o  4 2d01de73b03d: u [branch a]
> +| | | |
> +o---+ |  3 a00751ea823b: d [branch d]
> +|/ / /
> +| o /  2 eb935dd1d45b: c [branch c]
> +| |/
> +o /  1 483d9ec12c38: b [branch b]
> +|/
> +o  0 9a30ef678d2c: a [branch a]
[...]
> + ancestor eb935dd1d45b local df8f864b9dcd+ remote 61ecd8ec85ca
[...]
> +merging f
> +my f at df8f864b9dcd+ other f at 61ecd8ec85ca ancestor f at 2d01de73b03d
> + premerge successful

And with tip (with an added debug line) we get:

 ancestor eb935dd1d45b local df8f864b9dcd+ remote 61ecd8ec85ca
debug f at df8f864b9dcd+ f at 61ecd8ec85ca eb935dd1d45b
merging f
my f at df8f864b9dcd+ other f at 61ecd8ec85ca ancestor f at 9a30ef678d2c

This result is actually more correct (though the output is misleading).

- the overall merge ancestor is eb935 (rev 2 above)
- on the debug line, we've calculated the file ancestor as eb935
(matching overall)
- some idiot (me) decided to store the file level revision in the
mergestate
- file f is the same in revs 0 and 2
- when we perform the merge, we report the file level ancestor's linkrev
changeset in the debug message, which reports a different changeset for
the same file contents

First note that revs 2 and 4 are equidistant from the two revs being
merged (2 and 1 revs each) and from the root (1 rev), so Mercurial has
no good way to distinguish them topologically. It will choose a
different one depending on which order the branches appear
chronologically.

But why did this work before? Previously Mercurial was using changeset
level graphs to merge manifests and (less accurate) file level graphs to
merge individual files. While this sometimes gives a better result, it
makes the merge as a whole inconsistent: each file's ancestor might lie
in a different changeset, resulting in an inconsistent view of "the
ancestor changeset" across multiple file merges.

-- 
http://selenic.com : development and support for Mercurial and Linux