Fail to create .BASE when getting conflicts in some criss-cross merges
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
High
|
canonical-bazaar | ||
Breezy |
Triaged
|
High
|
Unassigned |
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_
# 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.
Changed in bzr: | |
assignee: | nobody → canonical-bazaar (canonical-bazaar) |
importance: | Low → High |
tags: | added: check-for-breezy |
Changed in brz: | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | removed: check-for-breezy |
Changed in brz: | |
importance: | Medium → Critical |
importance: | Critical → High |
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).