One useful feature of CVS, especially when maintaining several releases of a
software product at once, is the ability to make branches on the revision tree.
A D V E R T I S E M E N T
The RCS version numbers have nothing to do with the release numbers of the
software product. Therefore, CVS has the tag command which allows you to
give a symbolic name to a certain revision of a file. The -v option to the
cvs status command allows you to view any tags on a file.
Back to our example, go back to the first developers directory and issue a
cvs update foo.c
to get the current version of foo.c.
Next, we want to release version 1 of our wonderful software product.
To do this, we want to tag all files with the tag release-1.
cvs tag release-1 .
CVS should respond with cvs tag: Tagging .
T Makefile
T bar.c
T foo.c
T main.c
If some other developer wanted to check out release-1, he would issue the cvs
command:
cvs checkout -r release-1 project
He would then get the release version, instead of the newest version (if there
was one)
Now that we have made a release version, lets pretend we have started working on
version 2. Next thing we know, our customers are complaining about a fatal error
in version 1. Version 2 may be several months off in the future, and this bug in
version 1 needs to be fixed now.
First off, we can remove our two developmental trees from the previous
tutorials. There is a simple way to do this using CVS.
Go to the directory where your first project directory resides, and issue:
cvs release -d project
CVS should respond with You have [0] altered files in this repository.
Are you sure you want to release (and delete) module `project':
To this response: y
The -d option tells cvs release to delete the working copy.
You can now issue this same command for developer 2's directory.
Next we want to create a branch off version 1.
Go back to the original directory where project was and issue the command:
Next we need a working copy of the branch that was just created.
cvs checkout -r release-1-patches project
CVS should respond with cvs checkout: Updating project
U project/Makefile
U project/bar.c
U project/foo.c
U project/main.c
You can now fix the bug in version 1. Any changes committed will be committed to
the branch and not the main trunk.
Lets say the bug fix is to swap the YOU and TOO printf's in foo.c
Do this
[Or copy /class/bfennema/project_other/foo5.c to foo.c]
Next, check back in foo.c: cvs commit -m "Fixed printf bug" foo.c
It is also possible to merge the branch back into the main tree.
To do this, first release the patched version.
cd ..
cvs release -d project
Next, used the -j 'branch' option to cvs checkout to merge release-1 and
release-1-patches.
cvs checkout -j release-1-patches project
CVS should respond with cvs checkout: Updating project
U project/Makefile
U project/bar.c
U project/foo.c
RCS file: /class/'username'/cvsroot/project/foo.c,v
retrieving revision 1.3
retrieving revision 1.3.2.1
Merging differences between 1.3 and 1.3.2.1 into foo.c
U project/main.c
If there are any conflicts, they will have to be manually resolved.
After this is done you can now do a
cvs commit -m "Merged patch"
to commit all the files changed by the merge of release-1-patch into the current
source tree.
