Java™ Application Development on Linux - Dator

8.2 Source Control: Whys and Hows207Since your project would likely have more than one time in its life that itwould 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, butsuch 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 toreuse last cycle’s tag, or maybe you simply misspelled your tag), you can deleteit using the -d option.WARNINGOnce you delete a tag, it’s gone forever. It is not available even when you recallearlier versions. If you reuse a deleted tag, it doesn’t remember any history fromits 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 andyou fix it. What do you do with the tag? The tag will be on the unfixed versionof source. One thing that you can do, after you commit your changes, is simplyto move the label:$ cvs commit Account.java...$ cvs tag -F QA Account.javaThis 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 thatare put in shortly after the tag has been set down. But what if it takes QA severaldays to find the bug, and what if, during that time, you’ve been refactoringAccount.java, or adding features for a future release? In those cases, what youreally need is a branching tag.8.2.9 Branching TagsWhen you use the -b option with a cvs tag command, then the tag you createis a “branching” tag. That means that you now have two paths in your sourcerepository. You can check out source from, and commit changes to, either ofthose paths. This allows you to keep moving ahead with new development onthe head or tip of the source while providing fixes against a previous version.