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

Bug #494197 reported by John A Meinel
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

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:
  | \
 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.)

Tags: merge mysql
Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

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).

tags: added: mysql
Revision history for this message
Martin Pool (mbp) wrote :

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)
Changed in bzr:
assignee: nobody → canonical-bazaar (canonical-bazaar)
importance: Low → High
Revision history for this message
Martin Pool (mbp) wrote :

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

John, can you confirm/deny

Revision history for this message
John A Meinel (jameinel) wrote :

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.

Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
Changed in brz:
status: New → Triaged
importance: Undecided → Medium
tags: removed: check-for-breezy
Changed in brz:
importance: Medium → Critical
importance: Critical → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.