< Zurück | Inhalt | Weiter >

8.2.9 Branching Tags

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.


a.java v. 1.4

a.java v. 1.5

image

image

a.java v. 1.6

a.java v. 1.5

a.java v. 1.4

a.java v. 1.3

Head


a.java v. 1.4


a.java v. 1.5


QA


Figure 8.4 A simple branch and merge


Figure 8.4 shows a single source file with a single branch. The tag (QA) may have been applied to multiple files, typically to your entire project. The branched version of each file (for example, 1.3.1.1) is not created until the next change is checked in for that file, so many of the files with the tag may still be on their main source branch.



TIP

When do you want to create a branching tag? You can do it at any time that you lay down a tag. We have found it best to do it right away when you “release” your software, that is, whenever you hand it off to another group (e.g., QA or customers). This provides a label (the tag) to identify what exactly was handed off, but also puts the possibility for branching in place for fixes that may be needed on that branch.

image


Let’s look briefly at the steps you would take to lay down a branching tag named QA, and then apply a fix to that branch.

In the directory where you have your current source, which is what you just released, set down the branching tag:


$ cvs tag -b QA



NOTE

You have just set down the branching label on the source but you have not changed your current set of sources. If you make changes in the current direc- tory (and subdirectories) and check those changes in, you will be making those changes to the head, not the branch, of the source.

image


image

Example 8.3 Checking out a tagged revision

$ cd

$ mkdir fixes

$ cd fixes

$ cvs co -r QA myproject

cvs checkout: Updating myproject

...

U myproject/Account.java U myproject/Caltron.java U myproject/Demo.java

U myproject/Employee.java U myproject/Person.java

...

$ cd myproject

$ cvs status Account.java

===================================================================

File: Account.java Status: Up-to-date


Working revision: 1.2 Sat Oct 26 03:32:17 2002

Repository revision: 1.2 /usr/local/srctree/myproject/Account.java,v Sticky Tag: QA (branch: 1.2.2)

Sticky Date: (none)

Sticky Options: (none)


$


image


Now that you have the label set down, you need to check out a copy of that version of the source. Since we are checking out a new copy, be sure that your CVSROOT environment variable is set appropriately (see above). Then find some new directory to put your source and check out a copy with the tag, as shown in Example 8.3.

We did a cvs status after the checkout to show you the important dif- ference between this version and the other versions. These files will all show a Sticky Tag in their status. This is the label used to check out or update this version of the source. When you check in changes to these source files, the changes will be against that branch, and not the head.

From there on, everything is the same. Make your changes and just check files in as usual. CVS will remember (via the files in the CVS directory) that you’re on the branch, so when you check things in, they’ll go to the branch.

The important thing is to create the tag as a branch tag so that you can

commit changes against that branch. The downside, however, is that you now


have two different source versions; bug fixes have to be made in both sources, new features have to be added twice, and so on.

The easiest way to deal with that is to keep your number of active branch tags small; you likely don’t want to have to apply a fix to 14 different branches. Also, keep the lifespan of the branches brief—which is, of course, a relative term.

CVS does provide commands to merge a branch back into the source head. But for this, we will refer you to other CVS material. Our job is to give you an overview and a feel for the possibilities. For this sort of task you will want a complete reference manual.

For more variations on cvs tag, type:


$ cvs tag --help


8.2.10 cvs export

If you want to produce a copy of your source tree without the CVS subdirecto- ries—just the pure source—you can use the cvs export command. Like the inverse of import, it will check out a copy of the source, but will not create any of the CVS subdirectories that allow CVS to manage the commits, checkouts, logging, status, tags, and so on. In other words, the exported directories are not a CVS sandbox—they’re just a copy of the files.



NOTE

Changes made to an exported collection of files cannot be committed back to CVS. Of course you can get the changes back into CVS by creating a sandbox with a cvs checkout command, copying all or some of the exported files into that sandbox, and then committing the changes from there. But it’s better to think of export as a one-way street.

image