Using CVS

CVS (Concurrent Versions System) is a version control system, an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents.

CVS development seems to have slowed in the last few years. A new open-source project, started in 2000, called Subversion seems to be gaining market share. According to their website:

The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. The software is released under an Apache/BSD-style open source license.

This page will focus on “Lessons Learned” for CVS. Another page devoted to Subversion is forthcoming.

Tracking Third Party Software with Local Modifications

Sometimes you want to maintain a CVS repository of third party software (hereinafter: TPS) so that you can keep track of changes and fixes you make to it, and to keep track of versions released by the third party (hereinafter: 3P).

To initially set it up, get the software from the 3P. Whether you get a tarball (a gzipped tar file, usually with the double extension .tar.gz) or you obtain a version from the 3P's CVS server, you will start out with a directory (tree) of the TPS. From that (toplevel) directory, use the CVS import command:

    cvs import -m "useful comment" module VENDOR_TAG RELEASE_TAG1

module is the name of the CVS module you wish to store the TPS as. The VENDOR_TAG is an essentially useless CVS tag which you create, usually to identify the 3P (I suppose if you obtain the software from more than one party, it might be useful). The RELEASE_TAG1 is a unique tag you give to identify this release — this tag is extremely important if you ever want to update your CVS copy of the TPS with a new release from the 3P.

You can now check out module and have your own working copy of the TPS. After a while, you may have added a few things or made some bug fixes to the TPS, and then a new release of the TPS is announced by the 3P. You get this spiffy new version of the TPS and put it into a temporary directory somewhere… anywhere but your working directory. You then import the new release into your CVS repository:

    cvs import -m "useful comment" module VENDOR_TAG RELEASE_TAG2

Use the same module and VENDOR_TAG as before; but, you must specify a RELEASE_TAG2 that is different from before (or any previous time, if you do this more than once). After the import, CVS may tell you there are conflicts and give you a suggested command to resolve them. DO NOT, UNDER ANY CIRCUMSTANCES, EXECUTE THAT SUGGESTED COMMAND!

Go to some temporary directory (such as /tmp, if you have write access to it), and issue the following CVS command:

    cvs co -j RELEASE_TAG1 -j RELEASE_TAG2 module

Use the same module as when you imported it, RELEASE_TAG1 is the release tag you used when you imported the previous release from the 3P, and RELEASE_TAG2 is the release tag you used for the most recent release. This command causes all the changes between RELEASE_TAG1 and RELEASE_TAG2 to be incorporated into the current state of the trunk (containing your fixes and enhancements).

Now you need to search for unresolved conflicts. The command

    find . -name ".#*"

will help you find all those conflicts. The .#filename.x.y file contains your latest checked-in version (where x.y is the version number for that version), and the filename file contains CVS’s attempt to merge the 3P’s changes in with yours. Once you have resolved all the conflicts, check in the files you changed. Now you can delete this temporary directory and go do a cvs update in your working directory. Now, voila, you have the latest TPS with your personalizations still intact!