info-cvs
[Top][All Lists]
Advanced

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

Re: Rephrasing: question about merging branches


From: David Wood
Subject: Re: Rephrasing: question about merging branches
Date: Wed, 5 Nov 2003 09:45:20 -0500

Please correct me if I'm wrong. I _think_ this is the "greatest common 
ancestor" problem. And finding one is actually something CVS does for you 
- on the first mege (with a single -j). Which is usually OK in cases where 
a branch immediately "dies" (i.e. becomes dormant) afterwards.

The problem is that CVS does not "remember" that a merge took place. After 
a merge, the "map" of ancestry that was built by branch operations is no 
longer correct. And from that point on, CVS relies on _you_ to find the 
GCA. 

address@hidden wrote on 11/05/2003 
03:55:38 AM:

> 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?
> 
> Andy Jones.
> 
> 
> 
> 
> 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





reply via email to

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