These two purposes conflict with one another if QA is constantly pulling the latest code from the CVS repository since a developer may have done a check-in for the purpose of getting their code backed-up, sharing code with other developers, or because they have reached a logical level of completion and want to check point their code. By tagging code as being ready for QA, we enable developers to use CVS for source code control as often as they want without fear of interfering with QA or having to hold onto code for long periods of time without any checkpoint or backing up of it.
cvs co -r stable [filename]
Modify the code and check in your changes as often as necessary. You will need to clear the sticky tag from the files you change before checking in your changes. To do this fun the command:
cvs update -A [filename]
You only have to remove the sticky tag once from a file. After that you do not need to repeat this step before each commit of changes to a file (until you tag again with the "stable" tag name). You can use "cvs status" or "cvs log" to see if the sticky tag is still present. I believe CVS will prevent you from checking in a file that has the sticky tag set (since this is not a branch tag) so the above step must be done and no harm should come if you do not do it.
Then commit your changes as usual:
cvs commit [filename]
This will create a new revision while the "stable" tag will still point to the original revision.
If you want to add new files into CVS after you have checked out the stable tag, you must temporarily remove the stable tag from the directory that the files are in. This is done with the following command:
cd [your_dir]
cvs update -A
Then add and commit your file(s) as follows:
cvs add [filename]
cvs commit [filename]
Then tag the new code that you checked in with the stable tag:
cvs tag stable [filename]
Once all of your files have been tagged with the stable tag, you can optionally pull all of the tagged code for this directory again by using the update command:
cd [your_dir]
cvs update -r stable
Note that if you are going to be doing additional modifications to the files in this directory you may not want to pull the tag since you will have to clear the tag anyway before making changes to any of the files.
cvs tag -F stable [filename]
You can also set the tag to a specific revision number (for instance, to move the "stable" tag back a version) with the command:
cvs tag -r 1.6 -F stable [filename]
where 1.6 is the revision number.
This will checkout all of the code marked with the "stable" tag name.
Right click on the files to you are modifying and go to the "Update settings" dialog box. Check the "Reset any sticky date/tag/-k options" checkbox. Click OK. You can run the status command to see if the tag was removed from these files.
Commit your changes in the same manner that you do today.
cvs rtag -r stable qa [module]
cvs co -r qa [module]
cvs rtag -r qa rc [module]
cvs log [filename]
cvs status [filename]
cvs update -A [filename]
| stable | Updated by developers to indicate that the code has been unit tested and is ready for QA. | qa | Indicates that the code is being tested by QA. | rc | Indicates that QA has approved this code as a "Release Candidate". |
cd .../projects/platform
cvs -n update -r stable
The "-n" tells cvs to show you the output of the command without actually executing it.
You'll get a listing of all of the files that cvs was going to update in your working copy of the code.
Some example output is:
M test/src/com/foo/utils/db/publictest/data1/Projects01.csv
cvs server: New directory `test/testData' -- ignored
cvs server: New directory `webmod/ui/META-INF' -- ignored
U src/com/foo/utils/db/package.html
The "M" means that the file has been modified on your local disk and that the code has not been checked in yet (and thus the tag hasn't been updated yet).
The "U" means that the code has been checked in, but that it hasn't been tagged as "stable".
The other lines are new directories that were never added to CVS.