Re: Rephrasing: question about merging branches

[Jamie Wellnitz]

On Wed, Nov 05, 2003 at 08:55:38AM +0000, Andy Jones wrote:
> Is it just me, or is this getting way too complex to be usable except by 
> CVS experts?
> 
> I thought I was comfortable with the issues surrounding branches and 
> merges, even though we are not using branches yet here.  But I don't 
> understand half of what you folks are saying.
> 
> Worse: in my understanding this isn't even a particularly complex 
> case.  Let me see if I have this right.  You want to merge changes made on 
> a branch back into the main development stream, then merge that with the 
> changes on another branch.  Surely **everyone** will need to do this, 
> sooner or later?
> 

I think this is actually a somewhat complicated case.  An easier one
would be having two branches off the trunk and periodically merging
them both down to the trunk.  I think it's the "merge A to B and then
B to the trunk" that generates the complexity, especially if A and B
didn't branch from the same point.  More generally, maybe it's the
branch-to-branch merge that creates the complexity . . .

Handling multiple merges of a single branch down to the mainline is
actually quite easy (and more common), execept you have to keep track
of the merge points with tags.

> Andy Jones.
> 

Thanks,
Jamie Wellnitz

> 
> 
> 
> At 03:37 am 5/11/03, David Wood wrote:
> >I am not sure about something.
> >
> >> |>If branch A and branch B in your example don't branch form the same
> >> |>point on the trunk, a merge from point 2 to point 4 into the trunk
> >might
> >> |>still not do what you want.  If branch B branched first, then 2->4 may
> >> |>back out changes made to the trunk between the base of B and the base
> >of
> >> |>A.  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.
> >
> >Assume B is branched first. A merges to the trunk. Then A merges to B.
> >Then B merges to the trunk as well.
> >
> >I think the trick here is what happens when A merges to B. If you do that
> >merge like this:
> >
> >(in B's working dir):
> >cvs update -j branchA_CREATED -j 3
> >
> >(3 == where A merges to B) then you are correct. This merge will be
> >missing changes from between the start of B and A - ALREADY! In other
> >words, with respect to B, part of A was left out, since it was created
> >before "branchA_CREATED" - on the trunk. But I think this is really the
> >"wrong way" to merge A into B.
> >
> >The "right" way is to do it would be to say:
> >
> >cvs update -j branchB_CREATED -j 3
> >
> >Then branch B does indeed end up incorporating "everything" from branch A.
> >In other words, the changes on the trunk after B was created until A
> >starts, and then all then all the changes in A. So when doing that kind of
> >merge, always use the newest common ancestor (in this case, the start of
> >B).
> >
> >Now let's look at your other scenario. When A is created before B,
> >everything else being equal, I did not receive spurious conflicts doing
> >that last merge in a single step (2-4, Jamie's way) after all! You say
> >there should be, because that I am "remerging changes made to the trunk
> >between the base of A and the base of B." But I can't see where the
> >redundancy should come from.
> >
> >The changes between the start of A and the start of B are not in A, and
> >they are inherent in B.
> >
> >So goes my theory. Perhaps we are making different assumptions?
> >
> >> |>The only clean way to do this in the general case is to tag branch B
> >> |>before and after your merge from A at point 3 and merge B back into
> >the
> >> |>trunk as two merges:
> >> |>
> >> |>~    cvs up -j 1 -j pre-3
> >> |>~    cvs up -j post-3 -j 4
> >...
> >> Oops, yes, you are correct.  What I said was correct if point 2 & 3 were
> >> the same (at point 2 all of branch A was merge to both the trunk and
> >> branch B).  A clean merge to the trunk without conflicts from a repeated
> >> merge with distinct points 2 & 3 would require the two commands I listed
> >> above and a third merge:
> >>
> >> ~    cvs up -j 2 -j 3
> >
> >So if I understand you all correctly, a generalized merge formula would
> >be:
> >
> >cvs update -j start-of-branchB -j pre-3'
> >cvs update -j 2 -j 3
> >cvs update -j post-3' -j 4
> >
> >in that order?
> >
> >What if branchB had made changes that would conflict with branchA's
> >changes, and the merge from A to B is to correct that conflict and bring B
> >into sync _before_ it merges with the trunk?
> >
> >Following this pattern, I will still get that conflict between B and the
> >trunk on the first command - even though those conflicts had already been
> >resolved "post-3'". Nothing subsequent would work without manually
> >duplicating the conflict resolution already present in B...
> >
> >
> >_______________________________________________
> >Info-cvs mailing list
> >address@hidden
> >http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs