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

[Aaron Bentley]

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.

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
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.