[EMAIL PROTECTED] wrote: > Floating tags can also be used. For example, create a tag > called PRODUCTION and apply it to the next release. Then > just run "cvs update" > in the production area, and the proper versions will appear. Yep, that's basically the idea I was trying to get across.
> The down side to this is that if you don't apply unique tags > in addition to the floating one, you can't go back if > something breaks. Yes, that's a very important point. So, to summarize, I think we're in agreement in recommending this procedure: There are two floating tags. For discussion's sake, I will call them: QA_VERSION PRODUCTION The tag QA_VERSION is applied to a version that is ready to go to QA. The tag PRODUCTION is applied to a version that is ready to go into production. When a version is ready for QA, a unique tag is applied. I usually recommend that the tag incorporates the version number and build number, e.g. for rev. 2.1 build 17 of a project named PROJECT, the tag might look like PROJECT_2_1_17. The QA_VERSION tag is applied to that version, using: cvs rtag -rPROJECT_2_1_17 -Ff QA_VERSION project (or, if you prefer, 'cvs tag -rPROJECT_2_1_17 -Ff QA_VERSION' ) When the QA version is ready for production, then the production tag is applied, using: cvs rtag -rQA_VERSION -F PRODUCTION project During the maintenance window, the QA version is promoted to production by simply issuing a 'cvs update -dP' command. Don, feel free to disagree or to point out anything we may have missed ;-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs