3.7. Tags / Branches

3.7.1. Tagging a module

CVS automatically adds revision numbers to files when you check them in. But it is also possible to tag files or sets of files with your own label. That makes it possible to tag a current set of files with many different revisions as "beta_4" of "stableversion". That way you can easily go back to an older set of files by simple checking out the files with the same tag. So even if you already have progressed from beta_4 to beta_10, you'll still be able to compare the changes of a file or set of files between those two versions. You can also make a new branch starting at each tag. You add a tag to a complete module this way:

• Select Create > Create a tag by module

• Enter the tag-name (i.e. beta_5)

• Enter the module to be tagged (i.e. Version_4)

• Click OK

3.7.2. Viewing tags and branches in WinCVS

You can view the revisions and tags of a file graphical in WinCVS by rightclicking the file and selecting the Graph Selection command.

Depending on the changes made to the file and the tags attached to it, you'll see something like this:

Now that is more like it. You can see that readme.txt currently has revision number 1.7

The tag beta_4 is associated with revision number 1.3 and tag beta_5 is attached to revision number 1.7

Between those two tags, the file has been checked in a couple of times (revisions 1.4, 1.5 and 1.6)

If I want to know the changes made to the beta_5 version of the file (revision 1.7) compared to the beta_4 version (revision 1.3) I can compare them:

• press the SHIFT button

• click on both files to select them

• select Graph > Diff Selected

3.7.3. Retrieving an older version/tag

Because I tagged de module with the tag "beta_4" I can select to check out all the files that have that tag.

That means that I don't get files that don't have that tag (because the are newer), and that I get the revision of the file that belongs to that tag. In case of readme.txt that means I get revision 1.3, even though the current revision is 1.7

You probably won't do this with beta versions, but if instead of tags beta_4 and beta_5 you had tags for version 4.1 and version 4.2 and you discovered that there was an error in the readme.txt file. The error had been introduced in revision 1.2 and was still present in revision 1.7.

One way of fixing it would be to open the revision 1.7 file, fix the error there, save the file, commit the changes (CVS increases the revision number to 1.8) and release a version 4.2.1 which uses readme.txt with revision number 1.8 of the readme.txt file. No problem with that.

But what about the 4.1 version ? That version also has the error in readme.txt, but doesn't get updated. Let's fix that version also.

First, since we're going to retrieve the revisions that belonged to the old tag, then we're going to change the file with the error and then we'll upload the changed file back to the server again and have a look at how that affected our current version. I'll be showing this using the beta_4 and beta_5 examples:

• Select Create > Checkout module

• On the Checkout settings tab, check the 'override' option and enter a new name for the module: 'beta_4'

• On the Checkout options tab, check 'By revision/tag/branch' and enter the tagname we want to checkout: 'beta_4'

• Click OK

Now, all the files that have tag beta_4 get checked out into a new module that we also called beta_4. Because we didn't check them out to the default Version_4 module, that module stays unchanged. This way we can still keep on working on the current versions of the files while we are fixing the bug in the beta_4 version.

We can now go into the beta_4 module, open the readme.txt (with revision number 1.3) and fix the error. Then we commit the changes to the server. The revision number gets updated automatically again and is changed to 1.3.2.1

If we go back to our Version_4 module we can see that the revision of readme.txt we had there hasn't been altered, nor has the revision number changed. We can see what did happen if we graph the file again:

If someone checks out the most current version of readme.txt or the beta_5 tagged files, they will still get the 1.7 revision.