CVS Repositories

How to create and maintain repositories using the CVS version control system

Reviewed by Murray Anderegg 02/27/2013

Computer Services recommends Subversion and Git over CVS for code repositories. Computer Services still maintains CVS as a source code control system, but has very limited expertise in answering questions about CVS.


This page gives a brief introduction to CVS, including what is a CVS repository and who needs one, creation of a CVS repository, access to a CVS repository, how much space each user gets in a CVS repository, and other CVS-like repositories available in the UNC-CH Computer Science Department.  The book Open Source Development with CVS is available at  Other information is available online, and recommendations on other good sources are welcome.

The process of getting started with CVS may take a bit of time, so plan to try the CVS repository and read the online documentation to get up to speed.

What is a CVS repository and who needs one?

[This comes from Open Source Development with CVS, mentioned above.]  ‘If you’ve never used CVS (or any version control system) before, it’s easy to get tripped up by some of its underlying assumptions.  What seems to cause the most initial confusion about CVS is that it is used for two apparently unrelated purposes:  record keeping and collaboration.  It turns out, however, that these two functions are closely connected.

Record keeping became necessary because people wanted to compare a program’s current state with how it was at some point in the past.  For example, in the normal course of implementing a new feature, a developer may bring the program into a thoroughly broken state, where it will probably remain until the feature is mostly finished.  Unfortunately, this is just the time when someone usually calls to report a bug in the last publicly released version.  To debug the problem (which may also exist in the current version of the sources), the program has to be brought back to a useable state.

Restoring the state poses no difficulty if the source code history is kept under CVS.  The developer can simply say, in effect, “Give me the program as it was three weeks ago”, or perhaps “Give me the program as it was at the time of our last public release”.  If you’ve never had this kind of convenient access to historical snapshots before, you may be surprised at how quickly you come to depend on it.  Personally, I always use revision control on my coding projects now – it’s saved me many times.’

For collaboration CVS assumes all developers have equal status on a project, and provides them the ability to check out copies of a project, modify them, and then check in the copies independently.  At check in CVS checks each file being committed against the one currently in the repository, and in the case of conflicts alerts the developer that there is a conflict.  When there is a conflict, it is up to the second person committing to resolve the conflict before the repository will accept the new code.

Creation of a CVS repository

To create a CVS repository on the departmental CVS server, send a request to asking for the creation of a personal CVS repository, or for the creation of a project repository related to a research group or class in the department.  Personal CVS repositories are created on the CVS server in /cvs/user/<login> and project repositories are created on the CVS server in /cvs/proj/<project name>.

After the repository space is created, it is necessary to initialize the repository for CVS. Login to the CVS server and run:

cvs -d <repository directory> init

This will create CVSROOT and initialize all of the files in the CVSROOT directory.  If you wish to run multiple CVS repositories in your CVS repository directory, then you will need to run an init command inside of each repository subdirectory.  For example,

mkdir /cvs/user/anderegg/ruby-scripts
cvs -d /cvs/user/anderegg/ruby-scripts init
mkdir /cvs/user/anderegg/python-scripts
cvs -d /cvs/user/anderegg/python-scripts init

Access to a CVS repository

Access to any CVS repository is currently ONLY using SSH.  We strongly suggest that you use public/private key authentication with SSH, so that you are not prompted for a password for each file that is committed.  This makes the process of committing CVS changes more atomic and less painful.  A document describing how to setup public/private key authentication from Linux and Windows is available here.

The CVS repository is currently residing on a Linux server in an ext3 filesystem running POSIX draft file ACLs. The process of sharing a repository and collaborating with others will require modifying the ACLs.   For information on Linux file ACLs, see the man pages for setfacl and getfacl, and see these two web pages:  POSIX Access Control Lists on Linux and POSIX ACLs in Linux.

Here is an example on adding user anderegg to a repository in /cvs/user.  You need to set extended ACLs on your repository:

Login to cvs and:
cd /cvs/user/<your repository>
setfacl -R -m user:anderegg:rwX .
setfacl -R -d -m user:anderegg:rwX .

To remove access for user anderegg:
cd /cvs/user/<your repository>
setfacl -R -x user:anderegg .
setfacl -R -d -x user:anderegg .

NOTE:  Both commands need to be run to make a change in permissions on everything existing now (without -d) and everything created in the future (default = with -d).

There is a cron job that sweeps through the /cvs/user and cvs/proj repositories and performs a chown to the owner of the repository of everything within, in case a different user creates files within the repository.

How much space is allocated for users/projects on the CVS server?

Users are allocated 500MB of space for personal CVS repositories.  Projects are allocated 1GB of space for a CVS repository.

Other CVS-like repositories available in the UNC-CH CS Dept

The department offers and recommends two other repository managers:  Subversion and Git.  These repository managers are generally more robust than CVS.