merge_inner bug causes wrong merges
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
High
|
Unassigned | ||
Breezy |
Triaged
|
Medium
|
Unassigned |
Bug Description
This was exposed when I was looking at strict locking failures on
windows, in per_workingtree
affects bzr
importance high
status confirmed
done
merge_inner calls merger.
---
You shouldn't call set_base_revision if you don't want to set the base
tree, and you shouldn't set base_rev_id for the revision-id of a
WorkingTree.
For working trees, Merger does know about a basis revision, e.g.
Merger.this_basis and Merger.other_basis. There's no corresponding
variable for base trees, but that's what John would want to set.
The smallest change that would get this working would be to set
Merger.base_rev_id directly instead of calling set_base_revision.
Confirmed, that passes.
=== modified file 'bzrlib/merge.py'
--- bzrlib/merge.py 2009-08-20 03:06:50 +0000
+++ bzrlib/merge.py 2009-08-25 23:13:11 +0000
@@ -1520,7 +1520,7 @@
get_
if get_revision_id is None:
- merger.
+ merger.base_rev_id = get_revision_id()
return merger.do_merge()
def get_merge_
---
I'm worried that the way that set_base_revision is called could be
causing incorrect merges and/or conflicts when merging using the api -
for update, loom up-and down thread and the like.
Solving this will also fix the locking issue by allowing the tree passed
in to be used. I'm not really focused on this right now, thus the bug
report, but we should come back to it soon, thus importance high.
-Rob
tags: | added: merge |
tags: | added: check-for-breezy |
tags: | removed: check-for-breezy |
Changed in brz: | |
status: | New → Triaged |
importance: | Undecided → Medium |