[PATCH] test: merge fails since f153af9580fe

[Peter Arrenbrecht]

On Fri, Nov 13, 2009 at 7:41 PM, Matt Mackall <mpm at selenic.com> wrote:
[snip]
> 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.

Matt, thanks for the detailed analysis. This scenario is actually a
simplified view of situations that arise when pbranch needs to do
octopus merges at the branch level (simulated by repeated two-parent
merges into a hidden branch - branch d in the script I sent). I have
since realized that to automate such merges properly, I shall probably
have to add dedicated conflict resolution anyway. So I'm fine with
this change of behaviour.

Nevertheless, do you think it would be worthwhile for regular `hg
merge` to try all changelog ancestor candidates to see if any serves
to merge without conflicts requiring manual resolution?

(For the curious: pbranch conflict resolution should use the knowledge
that it's doing an octopus merge. The example above used to work
because only one of the branches being octopus-merged had a conflict.
If both have one, then you cannot avoid the conflicts just by ordering
the merges judiciously.)

-parren