Re: [Gnu-arch-users] Star merging with 3 branches

[Jan Hudec]

On Tue, Dec 09, 2003 at 12:49:54 -0500, Aaron Bentley wrote:
> Hi Jan,
> 
> On Tue, 2003-12-09 at 11:51, Jan Hudec wrote:
> > On Mon, Dec 08, 2003 at 17:49:59 -0500, Aaron Bentley wrote:
> 
> > > 
> > > We're using tla 1.1pre8
> > > 
> [snip]
> > > 
> > > Here's our current tree:
> > > 
> > > mainline
> > >    |
> > >    +-release
> > >        |
> > >        smallfeatures
> > > 
> > > First, went into mainline and did star-merge project--release--version. 
> > > Then I made CVS bring everything in mainline up to date.  Then I
> > > committed with tla.
> > > 
> > > So now, mainline should appear to be all of release, plus other
> > > changes.  Now there are changes in smallfeatures that I'd like to import
> > > into mainline.  So I do star-merge
> > > project--smallfeatures--version--patch-2.  And tla attempts to redo a
> > > bunch of the changes that are already present in both the release and
> > > mainline branches.  These changes don't have anything to do with
> > > smallfeatures--version--patch-2.  Smallfeatures inherited these changes
> > > from release.
> > > 
> 
> [snip]
> 
> > > So basically: have I misunderstood what star-merge is supposed to be
> > > capable of?  
> [snip]
> 
> > You have probably overestimated it's abilities. What it does is, that it
> > computes the "most recent common ancestor" and then applies delta
> > against this ancestor.
> > 
> > The limitation is, that only the two branches merged are by default
> > constidered candidates for the ancestor. So if you merge something from
> > release to mainline and smallfeatures, star-merge won't notice. You can
> > however tell it so (using --reference option).
> > 
> > However, even for "triangle" merge (as your case could be called) there
> > are combinations where it will invariably get lost and you will have to
> > carefuly look which revisions you have to replay or sync-tree to get
> > desired result.
> 
> That seems to be the case here.  The differences between mainline and
> release are abrupt.  If there were a series of smaller changes between
> release and mainline, star-merge might be able to reapply each
> successfully, but because the changes are so abrupt, the diffs probably
> mean "replace this file's contents with this".
> 
> > > Is delta the only way I can pull changes from smallfeatures into
> > > mainline?
> > 
> > start-merge might work with help of --reference, if the common ancestor
> > exists (and is in the named version). It might however happen, that
> > there are two uncompareable candidates for common ancestor and you will
> > have to use deltapatch, replay and sync-tree to resolve manualy.
> 
> I have also tried committing the smallfeatures changes into release,
> then star-merging to release.  This generates thousands of lines of
> .orig and .rej files.
> 
> But this all means that star-merge is using a totally different
> algorithm from the one I do by hand:
> 
> 1. Read merge history file for target ($ less lastmerge)
> 2. Determine which of the requested changes have been committed to
> source but not to target. ($ less ../release/lasttag)
> 3. Apply the selected changes to target. ($cvs update -j foo -j bar)
> 4. Update merge history for target
> 
> I'm not sure whether this algorithm is scalable, but it does seem to be
> automatable.  It's rather tricky to do by hand too, so I'd hoped Arch
> would be able to do it automatically for me.

It's tricky to do by hand principialy. And is impossible to do
automaticaly, since it does not have universaly defined semantics.

Problems with semantics arise, when there is no most recent common
ancestor (but instead several maximaly recent ancestors). When that
happens, what should happen depends on 

> Since it seems that the problem with using star-merge probably came from
> the abruptness of the changes, so we'll probably hold off using Arch

No. The size of the diffs only matters to diff when it tries to apply
fuzzy patch. However, the problem itself is mostly making too much mess
in merging.

Please, try to get merge-dependency graph of your branches. Acnestry
and ancestry-graph commands should help you a lot. Then try to locate
the common ancestor.

* Common ancestor is a revision that is part of both targets.

* Maximal common ancestor is a common ancestor, that is not part of any
  other ancestor.

* Most recent common ancestor is the maximal common ancestor if and only
  if there is only one. If there is more than one, there is no most
  recent ancestor.

If you can find the common ancestor, pass it to star-merge as
--reference and things will work.

If you can't find it, it's not possible to define semantics of the merge
anyway, so you can't ask a computer program to solve the mess you have.

> until our next branch point.  (If we're going to use Arch like CVS, we
> might as well use CVS, the devil we know.)  When we branch, we'll use
> Arch.  Then the changes should be gradual enough that they can be
> reapplied successfully.
> 
> Aaron
> 
> -- 
> Aaron Bentley
> Director of Technology
> PanoMetrics, Inc.
> 
-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>