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

[Aaron Bentley]

On Tue, 2003-12-09 at 13:20, Jan Hudec wrote: 

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

Well, it does sound from other postings like pure-merge is similar to
what I'm doing by hand.

> 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 

I'm not sure how we get maximaly recent ancestors...

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

Really?  If I have a patch A that inserts a line at position 25 in foo.h, and 
another patch B that replaces the entire contents of foo.h, it won't be 
possible to apply A then B without getting conflicts.
 
> 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.

I'm sorry.  While can use those commands, I don't know what you mean by
a merge-dependency graph.  

Sorry for the vertical graph here, not enough columns in email. 

mainline   release     smallfeatures 
  | 
  V 
base-0  
  | 
  V 
patch-2---> base-0 
  |           | 
  V           V 
(patch-3)   patch-1 --->  base-0 
  |           |              | 
  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. 

(Next time, I'm tempted to use dot format instead of ascii art...)

Hmm.  I think this might be where I went wrong.  Here release--patch-2
actually includes all changes from detour2 up to patch-1, but tla
doesn't know about that.  So when it tries to apply patch-1... 

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

That would be mainline--patch-2 and prior.

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

mainline--patch-2

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

I'm not sure how one would get more than one maximal common ancestor.  Unless 
merges count in ancestry.
 
> 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 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.

What I have isn't a mess.  My source management system works fine, I'd just 
hoped to automate more of it.

-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.