Fail to create .BASE when getting conflicts in some criss-cross merges

[John A Meinel]

Related to the fix for bug #40412, where we start creating .BASE files for --weave and --lca merge.

Also related to a hypothetical 3-way merge that uses per-file base selection.

The current code that drops .BASE/.THIS/.OTHER files checks to see if the file is in the respective tree before writing content to to disk.

However, you can have a criss-cross merge, such that you have to select an old global revision (before a file was created). Yet when looking at the per-file graph, there is a clear base content that could be used. Here is an example (this has been proposed along with the fix for bug #40412 as a XFAIL test test_merge_core.FunctionalMergeTest.test_weave_conflicts_not_in_base.)

        # A base revision (before criss-cross)
        # |\
        # B C B does nothing, C adds 'foo'
        # |X|
        # D E D and E modify foo in incompatible ways
        #
        # Merging will conflict, with C as a clean base text. However, the
        # current code uses A as the global base and 'foo' doesn't exist there.
        # It isn't trivial to create foo.BASE because it tries to look up
        # attributes like 'executable' in A.

If you look at the per file graph, it is simply:
  C
  | \
 D E

Which has an obvious BASE (C). The weave merge code even has content to give for base_lines. However 'bzrlib.transform.create_from_tree' requires more than just lines from the tree supplied. (Probably executable bit.)

[GuilhemBichot (guilhem-bichot)]

added tag as we saw this in a real-life weave merge when testing the fix of bug#40412 (how-to-repeat is in bug#40412).

[Martin Pool (mbp)]

I see this is still attached to a support ticket.

I'm not sure exactly what this bug is asking for. As part of bug 40412, we did add --show-base for weave merges. The rest of this bug seems to be "if we chose per-file bases for non-weave merges, we ought to use that for --show-base." I agree with that, but it necessarily depends on choosing a per-file base revision within merges, which is not yet supported. Doing so is I think covered by another open merge quality bug.

John, can you explain any more about this bug?

[Martin Pool (mbp)]

Bumping up to high because this is in sf case 00010349.

John, can you confirm/deny https://bugs.edge.launchpad.net/bzr/+bug/494197/comments/2

[John A Meinel (jameinel)]

The bug is that:

  We currently cannot create a .BASE file if the file doesn't exist in the unique_lca BASE revision.

There is a second bug which is touched on here, but not the explicit issue:
  We use the file text at unique_lca for BASE even when the per-file graph would indicate a better one.

I believe the former matters a lot to Guillheim because they cannot use a 3-way tool like kdiff3 to resolve the conflicts.

The latter matters less because it doesn't block functionality, but would certainly be useful because of improved accuracy.