[MERGE] iter_changes-based merge

Martin Pool mbp at canonical.com
Tue Jul 10 11:58:06 BST 2007

Martin Pool has voted +1.
Status is now: Approved
      def __init__(self, working_tree, this_tree, base_tree, other_tree,
                   interesting_ids=None, reprocess=False, 
-                 pb=DummyProgress(), pp=None, change_reporter=None):
+                 pb=DummyProgress(), pp=None, change_reporter=None,
+                 interesting_files=None):
          """Initialize the merger object and perform the merge."""
+        if interesting_files is not None:
+            assert interesting_ids is None
+        self.interesting_ids = interesting_ids
+        self.interesting_files = interesting_files
          self.this_tree = working_tree

Could you please document interesting_ids and interesting_files?

+    * merge now uses iter_changes to calculate changes. (Aaron Bentley)

Could you please say something there about why - if I understand
correctly, it's that this is meant to enable future performance

+    def _three_way(base, other, this):
+        #if base == other, either they all agree, or only THIS has 
+        if base == other:
+            return 'this'
+        if this not in (base, other):
+            return 'conflict'
+        # "Ambiguous clean merge"
+        elif this == other:
+            return "this"
+        else:
+            assert this == base
+            return "other"

I can't see how that assertion could ever fail at runtime, so you might 
well remove it and avoid the extra comparison.

This looks reasonable to me but because I'm not intimately familiar with
this code a review from someone else might be good.

For details, see: 

More information about the bazaar mailing list