RE: branch removal question

[Jim.Hyslop]

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)