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 sales@march-hare.com.
Andreas Krey wrote: > Yes, but that is true in any case of merges -- they don't always work > automatically, and it may be some work to actually make a correct merge > of all the functions from both source paths. But if you do that, then > a merge arrow is in order; if you don't (as in the case described > previously where you only take over selected functionality), then > placing a merge arrow is incorrect. 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). >> There is a solution (unidirectional merge, with a branch copy at the >> end) that provides all the benefits without the dangers of running such >> back-and-forth merges. > > This is a jump to the wrong conclusion. In our scenario we hade a branch > into which we merge from the head and placed merge arrows accordingly. > To get the branch work into the head we now have two choices: Do a > backmerge into the head, or do a merge from the head into the branch > and then copy the branch contents into the head. Assume the situation: > > 1.1---------+ > | | > | 1.1.2.1 > | | > 1.2 1.1.2.2 > | | > +-----> 1.1.2.3 Get more features into branch > | | > 1.3 1.1.2.4 Branch and head evolve further > > 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 1.1.2.4 Branch and head evolve further) > | | > +-----> 1.1.2.5 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 1.1.2.4, yielding > 1.1.2.5 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 1.1.2.4 Branch and head evolve further) > | | > 1.4 <-------+ Merge back into head, using patch > | | > > This backmerge goes to merge the diff from 1.2 to 1.1.2.4 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...) > 1.1---------+ > | | > | 1.1.2.1 > | | > 1.2 1.1.2.2 > | | > +-----> 1.1.2.3 Get more features into branch > | | > 1.3 1.1.2.4 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. 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. > 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. >> I fail to see the actual problem :) > > 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: > +-----> 1.1.2.5 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. > 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 1.1.2.5. merge, of course.) Something like cvs up -j tagBranchStart -j branch run on trunk does the copy-back-to-trunk. It needs a branch start tag, which is a good thing to have anyway. 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. Gerhard