CVS: An Introduction

If you have downloaded software from the Internet, especially from SourceForge, you probably noticed the letters CVS. CVS stands for Concurrent Versions System and is a tool that allows developers to keep track of their projects. It also allows developers to collaborate on projects.

While CVS may be used on large projects with many developers over a network, this article focuses on its usefulness for individuals on local systems. A common occurrence with CVS might begin with making changes to a script or configuration file and then moving on to other tasks. After some time has passed, you find your changes aren't working, and you don't have a backup of the original file, and you can't quite remember all the changes you made. CVS can help prevent this situation because it keeps track of changes made to files and allows you to revert to working versions of them.

Files under the control of CVS are stored in a special directory called a repository, and each file has a revision number maintained by CVS. To make a change to a file, you first must get a copy of it from the repository. You can get a copy of the latest revision of a file or any earlier revision stored in CVS. When you are through working with the file, you put it back into the repository, and its revision number increases incrementally. Each time you commit a file to the repository you can supply a log message that helps keep track of which changes were made to the file over time.

CVS differs from other version control systems in that it doesn't lock files; different developers can check out a file and work on it at the same time. CVS makes sure one developer's edits don't conflict with edits made by another developer when the file is put back into the repository. If conflicts are found, CVS places markers in the second developer's copy of the file, allowing him or her to find and resolve the conflicts. Once the conflicts are resolved, the developer then commits the file to the repository.

There is nothing tricky involved in installing CVS. You can either download and compile the source or install an RPM package or its equivalent.

Once CVS is installed you will have to decide where to locate the repository. It should be in a partition that has a good amount of free space and one to which you have write permission. Once you have decided on a location for the repository, you have to create it and populate it with CVS administration files. This is done using the CVS init command. If you want your repository to be in /usr/local/cvsstuff, you would execute the CVS command shown below:

cvs -d /usr/local/cvsstuff init

The CVSROOT environment variable, or -d switch, tells CVS commands which repository to act upon. The CVSROOT variable can be set by adding the following line to your .bash_profile:

export CVSROOT=/usr/local/cvsstuff

To put existing projects into the repository, use the import command. For example, say you have the directory structure shown below and will add other client directories in the future.

html_projects/
         client1/
            images/
         client2/
            images/

To place html_projects and everything under it into the repository, you would use the following commands:

cd html_projects
cvs import -m "Put html_projects in the repository" html_projects vendor release

If you were to now look in your repository, you should find a directory called html_projects containing copies of all the files in the original html_projects directory.

Creating a new project under CVS is simply a matter of creating an empty directory structure and then importing it into the repository via the import command. As you create the files for the new project, use the CVS add command to put them in the repository.