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.
"Vitaly Kouzin" <kouzin at infotecs.ru> wrote in message news:mailman.18.1155561780.3158.cvsnt at cvsnt.org... > We have been using mergepoint-based merging for about a year, but now > we seem to run into a sort of problem when trying to maintain several > versions of our product. > > Client/Server: Concurrent Versions System (CVSNT) 2.5.03 (Scorpio) > Build 2382. > > Consider the following scenario. We develop a project in the trunk. > When time comes to release version 1.0, we create a separate branch > for it, say b1, continue development in the trunk towards version 2.0, > and from time to time merge bug fixes from b1 to the trunk. Then to > release version 2.0, we create another branch, b2. Now we have to > support both 1.0 and 2.0, which means fixes made in b1 should be > applied to b2 as well. > > This is where the problem arises: when I try to merge b1 into b2, > CVSNT merges changes not from the nearest [b1->trunk] mergepoint but > from the b1 branchpoint, which results in a lot of conflicts. > > Is it possible to merge b2 to b1 using the correct mergepoints? And > more, what is the best strategy of propagating code changes across > different bugfix branches? Vitaly, 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'. 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. Cheers, John