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.
Andy, As Tony Eva pointed our - the thread discussing the technical stuff is available here: http://www.cvsnt.org/pipermail/cvsnt/2006-June/025200.html Your business case is quite reasonable. Merges are merges and copies are copies. You do not want to merge between your dev branch and trunk you want to copy. A merge implies - err - merging - and in your scenario there is nothing (or everything) to merge. If you want to maintain a similar process then you need to perform the copy as the last step as Gerhard explained. You can write a script to "copy trunk to HEAD" which will solve the problem of people forgetting a step or amend the cvsnt source code to create a "update --copy-from-branch". Alternatively amend your process. Example amended process: The "new development" is now on the trunk. When you create releases you create branches. The "minor" development to maintain a release goes on the branch. Now when you fix a "bug" in release 1, you commit it with a bug id. When you want to apply that same bug fix in the "new super version" (being developed on the trunk" you merge using the bug id. Alternatively skip the bug id's and just merge from branch-release-1 to trunk. Now when release 2 is ready (on trunk) - ie: all your release 1 stuff plus release 1 fixes plus release 2 development - you create a release 2 branch and can start all over again. It can get more complex - eg: you are maintaining release 1 and 2 and start work on release 3 (on the trunk). Release 3 is going to contain some new good stuff - but there are a couple of "big" features, either or both of which may not make it into Rel3. So you want to keep those changes separate until you decide they are ready to be merged in. EVS may handle this better than CVSNT does - but with CVSNT you're restricted to NOT merging any of the trunk or Rel 1+2 "bug fixes" into the "feature branch". That will be handled by the merge of "feature-a" into "trunk". We plan to have a new feature in EVS called "published commits" (versus "unpublished commits") that allow developers to commit things at intermediary stages - this will improve this. We (the developers of CVSNT) actually wrote a book on all this - and also cover promotion models and lots of other stuff - it's on the web site for purchase (as a part of CVS Suite) ;) Regards, Arthur