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. [EMAIL PROTECTED] 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 > >[EMAIL PROTECTED] > >http://mail.gnu.org/mailman/listinfo/info-cvs > > > > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs