Optimal Merge Base selection

Martin Pool mbp at sourcefrog.net
Mon Jul 11 02:47:31 BST 2005


On 10 Jul 2005, John Arbash Meinel <john at arbash-meinel.com> wrote:

> This change would mean trees with no real common ancestry, which only
> merged from a common group would not find their commonality. I mean
> something like this:
> 
> Me:    A - B - C - D - E - F
> #            /           /
> Other: G - H           /
> #            \       /
> You:   J - K - L - M
> 
> In this case, it would not find H as a merge base, since it is not along
> the main line of development for either tree.
> Though how 'H' got merged in, considering it doesn't share history, is
> left as an exercise for the user. 

H will get merged in as a two-way merge; that is to say by using the
empty tree as a base.  I did this the other day to bring in the weave.py
file, which started in a different directory.

This case works best when there is no overlap in the file names.  (It
might be nice if there was a way to merge the root of OTHER into a
subdirectory of THIS.)  

If any paths do collide they're likely to have different file-ids; in
the short term we need to choose one; in the long term it would be nice
to mark the file-ids as merged.

> Say somehow Me and You both merged a library (Other) into our main
> program. And then You update the library, and I want to merge your
> changes. In arch this could be done with a "baz replay M", which would
> even ignore any changes in M that did not effect shared code. I don't
> really know what "baz merge" would do. And now that it is after 1am, I
> can't think what it should do.

Does replay just ignore any patches that touch files not present in the
destination?   I suppose we could support such a behaviour as an option
to merge: don't update files that don't already exist, and disregard
files with the same name but different ids.

In arch, baz and bzr this will mean we record that replayed version as
merged, but in fact not all of the changes have been taken in.  That
might cause trouble later.  

I suppose this is a limitation of the basic assumption that merges are
tracked per-tree not per-file.  That could perhaps be relaxed, but it
seems to make things rather more complex.

-- 
Martin




More information about the bazaar mailing list