Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to email@example.com.
On Sun, 14 Jan 2007 13:27:28 +0000, Gerhard Fiedler wrote: ... > I agree with this. I'm only talking about what we both seem to consider a > "correct" merge (one that deserves a merge arrow, one that completely > integrates functionality from both code lines). Ok. :-) .... > > Now we are going to do it your way. We merge into the branch again > > and then copy the branch into the head: > > > > (1.3 188.8.131.52 Branch and head evolve further) > > | | > > +-----> 184.108.40.206 Get more features into branch > > | | > > 1.4 <=======X Do copy outside cvsnt. > > | > > > > For the merge we merge the diff from 1.2 to 1.3 into 220.127.116.11, yielding > > 18.104.22.168 which we then copy as 1.4 onto the head. > > > > Now, if we are doing it my way (patched cvsnt), then we simply do > > a backmerge: > > > > (1.3 22.214.171.124 Branch and head evolve further) > > | | > > 1.4 <-------+ Merge back into head, using patch > > | | > > > > This backmerge goes to merge the diff from 1.2 to 126.96.36.199 into 1.3, > > again yielding 1.4. > > How does this continue? (Below you said that one of the differences between > the merge-back-and-forth approach and the merge-forth-copy-back approach is > that the branch can or can't be used...) Basically, the existing merge arrows correctly describe the deeds done so far. So future merges in either direction will to the right thing (assuming the patch, of course). In contrast, with the copy-back operation cvsnt does not know about that transfer, and will do incorrect merge base selections for future merge between the two branches. > > > 1.1---------+ > > | | > > | 188.8.131.52 > > | | > > 1.2 184.108.40.206 > > | | > > +-----> 220.127.116.11 Get more features into branch > > | | > > 1.3 18.104.22.168 Branch and head evolve further > > | | > > 1.4 <-------+ Merge back into head, using patch > > | | > > For further development on the branch, you need to get the 1.3 > functionality on the branch. But not necessarily immediately. > Let's also consider that the back merge > created a number of conflicts that had to be resolved, like taking code > out, some reorganizing and everything we agreed upon earlier that may > happen in a merge. > > So, after the merge that created 1.4 (and maybe after some additional work > on both trunk and branch), you run again a merge from trunk to branch. How > does this work? Looks messy to me. Not really. If you directly merge back into the branch from 1.4 (and nothing has been done on the branch since) it actually degenerates into a copy. Otherwise 22.214.171.124 is now the effective common ancestor, and merges only deal with what has changed in 1.4 on the head (a lot and potentially messy stuff from the backmerge) and what changed on the branch since 126.96.36.199 (probably very little). If 'messy' meant the common ancestor selection: That now is 188.8.131.52 (as by the diagram above), independent of the direction of the next merge. ... > > Thus, merge forward and copy back produces the *same* result > > in the head as the merge-back-with-patch whose common > > ancestor selection Tony declared bogus. > > Maybe in the head; I'm not sure. But it definitely doesn't produce the same > result on the branch. Right. In merge-forward-copy-back the branch is (obviously) in the same state as the head, except that cvsnt does not know that. In merge-back it is in its original (pre-back-merge) state, ready to receive merges or do work on it. ... > > The only difference is that, after the merge-forward-copy-back, > > the branch is in a state where it can't be used anymore. > > Why is this? We started out considering a scenario where one has a branch > that one wants to keep up-to-date with the trunk while implementing a > feature on the branch. So this line, right before the copy-branch-to-trunk, > would be necessary anyway: > > > +-----> 184.108.40.206 Get more features into branch > > After this line, the branch has all features from trunk plus the new branch > feature. So I can copy it to the trunk, if I want the branch feature there. > There's nothing that prevents me from continuing development on the branch, > say to enhance the new feature. Yes, but you can't properly merge that work into the trunk any more. Nor can you merge new trunk stuff into the branch. The situation is: (1.3) +-----> 220.127.116.11 Get more features into branch | | 1.4 <=======X Do copy outside cvsnt. | In 1.4 the head contains everything from the branch so far, but the merge arrows don't record that fact. If you do a new merge from head to branch, regular cvsnt will merge the changes from 1.3 to 1.4 into the branch, although that is exactly the work that already has been done in the branch. A merge from branch to head fails anyway because regular cvsnt considers the branch root as the common ancestor in that case. Both will lead to spurious merge conflicts. ... > > And the copy-back is an operation that cvsnt does not provide and has to > > be done manually. > > I don't think this is correct. If you mean by "done manually" that one has > to use a command line command, you are correct. You could use a cvs update > command on the trunk to merge in the complete branch, from (branch) start > to (branch) tip. (After the 18.104.22.168. merge, of course.) Something like > > cvs up -j tagBranchStart -j branch > No. After the merge to 22.214.171.124 there is no need for a merge, the branch is in exactly the state you want the head to have (you already merged the head with the branch). But you are right; you can use cvs to do that: cvs up -j HEAD -j branch If you *don't* do the merge-to-branch resulting in 126.96.36.199, then you can do: cvs up -j 1.2 -j branch Your cvs up -j tagBranchStart -j branch will try to merge all the head/trunk changes that have been merged into the branch (and that are *all* changes on the head) back into the head where they already are. This gets you a lot of spurious conflicts (which is exactly the way we noticed that cvsnt lost the merge-arrow-controlled bidirectional merge capability). > run on trunk does the copy-back-to-trunk. It needs a branch start tag, > which is a good thing to have anyway. Due to the lack of '-rbranch:BASE'. :-) >It also can be repeated after having > been done once, if one tags the branch at this merge (also a good thing to > do anyway) and uses now this new tag as start reference. It was my impression that the merge arrow business was to avoid this bookkeeping (which gets especially nasty if you occasionally only merge specific parts of the tree instead of the while project). Andreas -- np: 4'33