12 October 2004 - 20:38Intro to CVS

I use CVS as my source control system for essentially everything. Although some of the tools that interface with CVS such as Eclipse, there are a whole lot of tricky, painful CVS details that can sneak up on you. Not only that but using the command line version of CVS can be even more daunting since the one cvs executable handles all the 31 commands. Information references such as ‘man cvs‘ and ‘info cvs‘ are helpful, but the length of both is extreme. I’ll try to go over some of the benefits, setup, and use in this article and more to follow.

Intro

The benefits of the Concurrent Versions System is not initially apparent to someone with little programming experience working on small independent projects. The need for it becomes clear when you start to have multiple developers, multiple development machines, a need to show the previous versions of files, and multiple variants of the same product. CVS helps with each of these aspects. Unlike RCS it allows files to be modified simultaneously by two people at the same time and CVS provides the tools to merge the differences. Unlike Visual Source Safe, it’s cross platform, and has an open protocol. It has also been around for almost 15 years so it’s proven itself in action.

Installation

Installation was easy for me since it’s available in the FreeBSD by default. It’s also installed by default in many other *NIX distributions. Installation should be fairly easy and instructions, sources, and binaries can be found at the CVS home page.

Repository

The repository is the location where the binary version files are held. A repository contains modules which are essentially projects under version control. You create a repository with the following:

cvs -d /usr/cvsroot init

This will setup all of the necessary files for the repository. The -d flag must be used to specify the repository location or the CVSROOT environment variable must be set. I’ll assume that you have set the environment variable for all of the following examples but remember the -d flag can be used in it’s place.

You can add your first project by starting in the root folder of your project and using the import command. It’s very important that your INSIDE the root folder of your project. The import command can be used as follows:

cvs -d /usr/cvsroot import -m "Imported sources" thegillis/myproj thegillis start

In this case, the -d flag specifies the repository, the -m flag specifies the message. If this is left out, the default editor will let you specify a message. ‘thegillis/myproj’ is the folder inside the repository, and is the folder that you specify to checkout the project. ‘thegillis’ and ’start’ is a vendor tag and a release tag. We won’t use them here, but lets just say that the vendor tag should be changed to a meaningful vendor name for you. Notice the -d flag appears before the import action. This is important as is the location of the -m flag.

Congratulations! You’ve now added your project into source control. Before it can be checked out in the current location, the folder must be removed or renamed or CVS will complain.

Working With Projects

To begin to work with the project, use the checkout command.

cvs checkout thegillis/myproj

This will create the current version of the project in the current folder. Now files can be edited as needed. When you finish editing a file you can check in the single file with:

cvs commit file.c

With commit the -m flag can be used to insert a comment. Commit without a file will commit all changes. New files can be added with the add command.

cvs add newfile.c
cvs commit

After the add, the file has to be committed. To remove a file:

rm filename.c
cvs remove filename.c
cvs commit

Don’t worry, the file is not really gone, just stored in a special Attic folder on the server. Before a cmmit is made, or to update old files, the cvs update command can be used.

cvs update

or,

cvs update filename.c

Some common prefixes for files are:

• P - Patched, a patch was used to update the file from the server to save bandwidth.
• U - Updated fro
• m server.
• M - Modified, the file was modified and needs to be committed.
• A - Added, the file will be added.
• R - Removed, the file will be removed.

I’m sure there are others, but these are what I can remember from memory.

Problems

I haven’t covered a lot. Almost nothing in fact, but this should at least allow you to get started. So far I’m only referring to text files. Binary files get tricky. I haven’t talked about getting older versions of files, tagging, branching, remote repositories, permissions, administrative files… The list seems endless for now. At least you can start becoming familiar with how CVS works.

Summary

CVS works great as a source control system for most project setups. I currently can’t think of a situation where CVS would not be a valid choice as a source control system. I think it’s also nice that it can scale from one user working with a local repository, to many users working with a remote repository. Administration becomes the difficult part. Some of the commands are dangerous if used incorrectly, and access control can be tricky. I’ll attempt to go over some of these problems in the future. As you probably know, I am also still learning. If your brave or stuck, check out the references.

References:

• ‘man cvs‘ - Great Reference
• ‘info cvs‘ - Great Information
• CVS Home