[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: branch removal question
From: |
Jim.Hyslop |
Subject: |
RE: branch removal question |
Date: |
Wed, 23 Jun 2004 11:43:40 -0400 |
address@hidden 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)