Java Reference
In-Depth Information
Since your project would likely have more than one time in its life that it
would be handed off to
QA
, some people will put date information in the tag,
for example,
QA_2003_07_15
. Others will use a simple tag, such as
QA
, but
such a tag may need to be reused.
If you've put down a tag and decide that you no longer want that tag
(for example, your product is preparing for a new
QA
cycle and you want to
reuse last cycle's tag, or maybe you simply misspelled your tag), you can delete
it using the
-d
option.
WARNING
Once you delete a tag, it's gone forever. It is not available even when you recall
earlier versions. If you reuse a deleted tag, it doesn't remember any history from
its first use.
Imagine your project has just reached a milestone, like the hand-off to
QA
,
so you have tagged your source accordingly. Now the
QA
group finds a bug and
you fix it. What do you do with the tag? The tag will be on the unfixed version
of source. One thing that you can do,
after
you commit your changes, is simply
to move the label:
$ cvs commit Account.java
...
$ cvs tag -F QA Account.java
This will “force” the tag on
Account.java
to move to the current version.
Such a mechanism works fine for the short term, for quick changes that
are put in shortly after the tag has been set down. But what if it takes
QA
several
days to find the bug, and what if, during that time, you've been refactoring
Account.java
, or adding features for a future release? In those cases, what you
really need is a branching tag.
8.2.9
When you use the
-b
option with a
cvs tag
command, then the tag you create
is a “branching” tag. That means that you now have two paths in your source
repository. You can check out source from, and commit changes to, either of
those paths. This allows you to keep moving ahead with new development on
the head or tip of the source while providing fixes against a previous version.
Branching Tags
