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.
Hi Jonathan, This is a topic we covered with the onsite training last year. Please re-read the eBook section on promotion models - what you have described is exactly what promotion models solves. A quick overview of promotion models follows that all may be interested in. Our eBook is the primary reference for this (which is not open source, but can be purchased from the web site as a part of CVS Suite). Instead of "tagging" the files with rel_c1234567 you have a branch called "promote_release" which has an ACL on it to only allow your QA staff to make changes, also all the files on this "branch" (promotion level) are "-ko". Now the QA staff "promote" the work on the trunk to "promote_release" (cvs up -j HEAD .) and then commit it and tag it with "RC1" (or whatever) and alias the tag rel_c1234567 to RC1 (cvs tag -A -r RC1 rel_c1234567 .). A bug fix is done on the trunk and committed with a bug id. Note: the cvs suite server you put into production allows you to automatically translate a message such as "bug 123" to a "real" bug id that is stored in the RCS file, check /etc/cvsnt/PServer.example for instructions. Let's say the bug fix was 123. Now the QA staff "promote" the bug 123 on the trunk to "promote_release" (cvs up -j HEAD -B 123 .), and then commit it with "cvs ci -B 123" and tag it with "RC2" (or whatever) and alias the tag rel_c1234567 to RC2 (cvs tag -F -A -r RC2 rel_c1234567 .). Of course it is typcial to have more promotion levels that just "release", eg: build, review, function test, integration test, release/acceptance test. Please contact support for questions specifically about the eBook documentation. Regards, Arthur Barrett -----Original Message----- From: Harding, Jonathan [mailto:jonathan.harding at wachovia.com] Sent: Thu 8/30/2007 6:02 AM To: support Cc: FIRE-CVS; cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: Combining a tag which contains all files with a tag which only contains a subset I am attempting to document the procedure for preparing a CVS sandbox which can be used to produce a build for a patch release. Example: I have a repository with 3 files. File1.txt File2.txt File3.txt I have applied a tag to all of these files names rel_c1234567 After the release went into production, a bug was found which required a modification to file2.txt. The developer modified file2.txt and tagged with with the name patch_change. How can I combine the production tag with this new tag which only contains this one modified file? This will extract my current production files: cvs co -r rel_c1234567 1dev cvsnt server: Updating 1dev U 1dev/add.txt U 1dev/file1.txt U 1dev/file2.txt U 1dev/file3.txt I would then expect to be able to cd into the 1dev directory and execute a cvs up -r patch_change and pull in only file3.txt, but that isn't the case. This is what I see: $ cvs up -r patch_change cvsnt server: Updating . cvsnt server: file1.txt is no longer in the repository cvsnt server: file2.txt is no longer in the repository U file3.txt It removed the other files. What am I doing wrong? Is this even possible without checking the repositories out separately and combining them using OS specific commands like cp ? Jonathan Harding Assistant Vice President and Release Engineer