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.
John Hall wrote: > This has come up before, and the poster was told that this is the expected > behaviour. I can't quite see why CVSNT couldn't work out the correct merge > to do, but then I'm no expert. > This is a problem I, too, recently encountered. I ended up writing a perl > script that walks the tree and does a 'cvs log' per file, works out whether > the a merge has already been done from b1 to b2. If so, it just issues a > 'cvs update -j b1 filename', if not it finds the last mergepoint on the > trunk from b1 (I'll call it mergepoint, which is a revision on b1) and > issues 'cvs update -j mergepoint -j b1'. Thanks, John. I've found the thread. From what I've read I've learned there are two possible solutions to the merge problem: (a) create bugfix branches so that they share the same branchpoint, and (b) for the first time merge the branches using a script, then rely upon the new mergepoints. Because the first approach would imply unobvious restrictions on branching, I'm inclined too to write a script (I'm more familiar with Python). > The script is very slow, since it issues two cvs commands per file, and also > doesn't support files added to branch b1, but it does work. For us, the > number of commits to b1 will be fairly small now that we have b2, and will > decrease to zero over time, so I can cope with the deficiencies of this > approach. The speed is not an issue for us :) By the way, I think taking into account files added on a branch wouldn't be too difficult. One can issue "cvs log" for the whole directory tree: the output should contain information on all the files in the tree, not only on those on the current branch. Thanks again for your help. WBR, Vitaly