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 firstname.lastname@example.org.
Andreas Krey wrote: 1.1---------+ | | | 18.104.22.168 | | 1.2 22.214.171.124 | | +-----> 126.96.36.199 Get more features into branch | | 1.3 188.8.131.52 Branch and head evolve further | | 1.4 <-------+ Merge back into head, using patch | | 1.5 184.108.40.206 Branch and head evolve further | | +-----> 220.127.116.11 Get more features into branch - see below >> For further development on the branch, you need to get the 1.3 >> functionality on the branch. > > But not necessarily immediately. I meant it was needed. Not for the merge process's sake, but because the functionality was needed. >> 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 18.104.22.168 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 22.214.171.124 (probably very little). Let's say there were changes in both branches (.5 in the diagram above). > If 'messy' meant the common ancestor selection: That now is 126.96.36.199 > (as by the diagram above), independent of the direction of the > next merge. How does this "grab" the changes that happened between 1.2 and 1.3 when you merge into the branch and create 188.8.131.52? > 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) > +-----> 184.108.40.206 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. You are correct, I missed this. >>> 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 220.127.116.11. merge, of course.) Something like >> >> cvs up -j tagBranchStart -j branch > > No. After the merge to 18.104.22.168 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). Yes, you are right again... :) I actually never did it that way, I always used a three-step approach (copy branch to trunk, add files that are new on trunk, remove files on trunk that are not on the branch). This merge command is what Tony H suggested, in that earlier thread, and I thought I understood it. I wish Tony H or Arthur would explain better the situation(s) they have seen that lead to data loss. IIRC, so far it was only a "trust me on that" or something the like... I think it would be extremely helpful if the situations that lead to data loss were described somewhere in a way that allows them to be reproduced. Gerhard