Re: Rephrasing: question about merging branches

[David Wood]

Derek Robert Price <address@hidden> wrote on 11/06/2003 04:37:03 PM:
> I see it now, and I thought that the conflicts you now say don't occur
> were the ones you objected to in the first place.

Not at all. The conflicts that troubled me were happening because I was 
double-merging (when bringing B back to the trunk, merging from 1-4 
instead of 2-4), _until_ I used the technique laid out in that email.

The conflicts in question are what you describe, here: 

"If A branched first, then 2->4 will attempt to remerge changes made to 
the trunk between the base of A and the base of B, causing the same sort 
of spurious conflicts you were attempting to avoid." 

And that did not seem to be true. 

It seemed to me that those changes are not merged twice - as I said, "The 
changes between the start of A and the start of B are not in A, and they 
are inherent in B." So I am wondering if I tested it wrong and am thinking 
about it wrong? 

> Regardless, some of what you said in that email was correct and some
> wasn't, but I don't think you can solve the general case without saving
> a merge history for each revision of each file.

If individual files can't merge, and only whole branches can, I confess I 
don't understand why that is true, unless by saying the "general case" we 
are actually discussing something different than I imagine.

One other thing I was wondering about was what I found when experimenting 
with the approach you suggest (using multiple merges): that conflicts 
arise during the interim steps, making the process unworkable. 

I am interested in single-step merges both because it _seems_ possible 
generally to construct one appropriate to a given case, and because they 
appear to me to avoid the issues of conflicts during interim merge steps.

> It isn't.  The existing GCA algorithm is merely a convenience to avoid
> typing a start-revision in the most common case (merging from a branch
> to its parent) and I think it actually confuses more people than it

Let me clarify what I mean a bit more. I want to generalize the process of 
finding a merge start point based on merge and branch information. I think 
the CVS "GCA" system is an interesting approach when working with branch 
information alone. 

If I understand it correctly, it is analogous to walking backwards up the 
ancestry of the source branch, searching for the most recent branch point 
on any common parent, of the souce or the destination branch (whichever is 
older).

What I am experimenting with is the notion that if you add merge 
information to the mix, this approach still works. I am gathering that you 
don't think it will; but I guess what I am wondering, in that case, is, 
"how will it fail?"