gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Hudec
Subject: Re: [Gnu-arch-users] Star merging with 3 branches
Date: Thu, 11 Dec 2003 11:16:51 +0100
User-agent: Mutt/1.5.4i

On Wed, Dec 10, 2003 at 13:40:56 -0500, Aaron Bentley wrote:
> On Wed, 2003-12-10 at 11:25, Jan Hudec wrote:
>
> > > mainline   release     smallfeatures 
> > >   | 
> > >   V 
> > > base-0  
> > >   | 
> > >   V 
> > > patch-2---> base-0 
> >      ^-- this is what tla considers most recent common ancestor
> > >   |           | 
> > >   V           V 
> > > (patch-3)   patch-1 --->  base-0 
> >                  ^-- this is the actual most recent common ancestor, but
> >              tla won't see it unless you explicitely tell it to look
> >              in release branch.
> > >   |           |              | 
> > >   V           V              V 
> > > patch-4<X---patch-2       patch-1 
> > >                              | 
> > >                              V 
> > >                           patch-2 
> > >
> > > <X--- is a bogus merge.  It was originally done via CVS, and I simply
> > > star-merged, then clobbered with the CVS result.  But tla shouldn't know
> > > that I didn't do it by hand. 
> > > > 
> > > > * Common ancestor is a revision that is part of both targets.
> > > 
> > > That would be mainline--patch-2 and prior.
> > 
> > And release branch does not contain any ancestors??? If I understand the
> > above correctly, the merge release-2 -> mainline-4 did happen. Thus
> > release-0 and release-1 ARE common ancestors.
> 
> This was a terminology problem.  I thought you only considered ancestors
> through *branching*, not merging.

Since common ancestor is used as point of departure for merging, it must
reflect previous merges.

> > > > If you can find the common ancestor, pass it to star-merge as
> > > > --reference and things will work.
> > > 
> > > Okay, I'll give it a shot once I've rebuilt my tree to reflect the fact
> > > that release--patch-2 includes smallfeatures--patch-1.
> > 
> > If I understand the graph above correctly, release--patch-2 does NOT
> > include smallfeatures--patch-1...
> 
> The graph represents what I did in tla, not what originally happened in
> CVS.  In tla, I forgot to "merge" smallfeatures into release before
> "merging" release to mainline.  (Bogus merges, of course, clobbering the

If you merged the code, but not did it via tla, then you must tell tla
it happened. Tla does not understand the code, it only understand the
logs. You can tell tla that something was merged via the sync-tree
command (in a working copy do a sync-tree <revision> adds all logs in
<revision> to that working copy). This you use either if you want to
revert changes (you don't merge them but from tla's point of view you
merged and undone them) or, as is your case, when you apply them by
other means.

> directories with the appropriate tagged CVS versions, instead of
> manually fixing the conflicts).
> 
> I believe that will make the most recent comment ancestor
> smallfeatures--patch-1, which makes sense to me, considering the only
> changes I believe should be applied are from smallfeatures--patch-1 to
> smallfeatues--patch-2.

Yes. If you tell tla, that smallfeatures--patch-1 is actualy merged (via
sync-tree), tla will take it as the most recent common ancestor and
merge only delta between smallfeatures-1 and smallfeatures-2.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]