merge_inner bug causes wrong merges

[Robert Collins]

This was exposed when I was looking at strict locking failures on
windows, in per_workingtree.test_workingtree.*test_merge_revert

 affects bzr
 importance high
 status confirmed
 done

merge_inner calls merger.set_base_revision unconditionally. Aaron says:
---
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_revision_id = getattr(base_tree, 'get_revision_id', None)
     if get_revision_id is None:
         get_revision_id = base_tree.last_revision
- merger.set_base_revision(get_revision_id(), this_branch)
+ merger.base_rev_id = get_revision_id()
     return merger.do_merge()

 def get_merge_type_registry():

---

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