Introduction to CVSby Jennifer Vesperman
This is the first in a two-part series on CVS. This article is intended for folks who will be using CVS already installed on a system. In it, the author explains check-out, update, adding, merging, and other functions. In the second part, scheduled to run later this month, she will show how to create and manage a CVS repository, for those who need to start from scratch. -- Ed.
CVS -- or Concurrent Versioning System -- is a system for managing simultaneous development of files. It is in common use in large programming projects, and is also useful to system administrators, technical writers, and anyone who needs to manage files.
CVS stores files in a central repository, set (using standard Unix permissions) to be accessible to all users of the files. Commands are given to "check out" a copy of a file for development, and "commit" changes back to the repository. It also scans the files as they are moved to and from the repository, to prevent one person's work from overwriting another's.
This system ensures that a history of the file is retained, which is extremely useful when the boss decides he wants a feature you trashed months ago. It also ensures that backing up the repository is enough to backup a project (providing all necessary files are kept in repository).
CVS is usually used to help manage projects, but can also be used for individual files.
CVS is designed for developers, either individually or in teams. For individuals, CVS provides a repository from which you can work from home, the office, or the client site without having to haul disks around. It also provides version control, allowing rollbacks without loss of data. For teams, it also keeps a record of who changed which lines of a file and prevents direct overwriting of each other's work.
System administrators can keep configuration files in CVS. You can make a change,
cvs commit it, test it. If it fails, roll back the change -- even if you only discover the failure six months down the track.
Administrators can keep a CVS tree of the configurations for server farms. Adding a new server? Just
cvs checkout the config tree for that type of server. Committing all changes also helps you keep track of who did what, when.
CVS is useful for writers. I keep these articles in a CVS tree -- if I lose my local copy, I have an automatic backup. It is also useful if I'm collaborating, or if I discover that I need to retrieve a section I'd removed.
Notes For the Examples
The examples in this article assume that there is a pre-existing CVS repository for the project.
The next article in this series will be "CVS Administration," which will explain how to create a CVS repository, branch projects, and manage the repository. For now, check
cvs init and
cvs import in the
cvs man page.
Necessary Environment Variables
If you expect to use one repository, set the
$CVSROOT environment variable to the repository's full path, in the format
:protocol:user@host:path. It should look something like
For security, set the
$CVS_RSH environment variable to
ssh. By default, CVS uses
rsh to access a repository on a remote machine.
Getting the Tree: cvs checkout
CVS stores the files in a central repository, but users work from a working copy of a file.
- Make a directory to do your work in. I tend to use
cdinto that directory.
cvs checkout module, e.g.
cvs checkout example. (
moduleis CVS' name for a related collection of files.)
If you don't have a
$CVSROOT environment variable, or want to use a different repository, use
repository-path to checkout the module instead.
The checkout will put a copy of that module's files and subdirectories into your
cvs$ ls example cvs$ cd example; ls CVS src cvs/example$ cd CVS; ls Entries Repository Root
CVS directory is a special directory CVS uses for its own purposes.
CVS/Entries lists files and subdirectories CVS knows about.
CVS/Repository contains the path to the corresponding directory in the repository.
CVS/Root contains the path to the repository, so you won't need to use the
-d repository-path option again for these files.
CVS/Root overrides the
$CVSROOT environment variable, so if you change the repository, you should check out the module again.
cvs/src$ ls CVS Makefile sample.h sample.c
src directory contains the source files for the example project.
Makefile are ordinary files in the working copy -- in the repository, they are stored in a format which tracks the changes.
Receiving Changes: cvs update
Every day before you start work, and any time someone else may have made and committed changes,
cd into your working directory and run
cvs update. This checks your working copies against the repository files and imports any changed files for you.
cvs update -d also gives you any new directories.
Update reports on the status of each file as it checks it:
- U file
- updated successfully
- A file
- added but not yet committed (need to run a
- R file
- removed but not yet committed (need to run a
- M file
- modified in your working directory: the file in the repository was changed and your working directory file was older than the last time CVS checked it OR the repository had changes which the system could safely merge
- C file
- there was a conflict between the repository copy and your copy which requires human intervention
- ? file
- the file is in your working directory but not the repository and CVS doesn't know what to do with it
Pages: 1, 2