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

[Aaron Bentley]

On Wed, 2003-12-10 at 11:25, Jan Hudec wrote:

> > 
> > Well, it does sound from other postings like pure-merge is similar to
> > what I'm doing by hand.
> 
> Yes, but it is still limited, this time it relies on the changesets
> being either pure changes or pure merges.

Ah.  Well, that's a restriction I've been enforcing anyhow. 
Changeset-based CVS is rather like object-oriented C. :-)


> > 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. 
> 
> It depend on what you did with the patch-logs. If you star-merged, they
> should be there, but better check ;-).
> 
> > (Next time, I'm tempted to use dot format instead of ascii art...)
> 
> Please stick to ascii art. I would probably not bother to look up
> something to read it.

Dot format would be something like:
digraph repository
{
"mainline--base-0" -> "mainline--patch-2"
"mainline--patch-2" -> "release--base-0"
"mainline--patch-2" -> "mainline--patch-3"
}


Which Dot turns into pretty pictures like this:
http://www.panoramicfeedback.com/images/tla.pdf

Not quite as human-readable as the ascii art, but pretty
straightforward.

But sure, I can keep drawing with vertical bars and Vs and things.

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


> > I'm not sure how one would get more than one maximal common ancestor.  
> > Unless merges count in ancestry.
> 
> With 4 branches quite easily. However, I am not sure whether it can
> happen with 3 branches:
> 
>    A     B     C    D
>    |     |     |    |
>    1<----1-- --1--->1
>    |     |  X  |    |
>    2<------- ------>2
>    |     |     |    |
>    3                3
> 
> the X is crossing of the arrows -- B1 is merged to A1 and D2; C1 is
> merged to D1 and A2. Now, both B1 and C1 are maximal common ancestor,
> but neither is ancestor of the other. So there is no most recent common
> ancestor and the decision how to merge must be done manualy.

Ah.  That does look like a troublesome situation.

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

Aaron

-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.