introduction to Concurrent Versioning System
Concurrent Versions System is a popular open source version control system.
Although it is mostly used to track changes to software source code for
development teams, there are very few limitations to the kind of data that can
be managed by the system, and it can be used for document archival purposes as
This document provides an introduction to using OpenCVS to manage repositories.
It will first cover some of the aspects of using and managing CVS and, where
appropriate, explain the main differences between OpenCVS and other
One of the most common uses of
is to track changes to a collection of source files (a
) contained within a certain, defined,
location (a repository
). This allows the user to
keep a set of local sources in sync with a set of remote sources. It also
allows the user to view information about changes to the repository (such as
what the exact change was, who made it, and when), to view and compare
information about different versions of a file, and possibly to make local
changes to files.
As an example, we'll look at a user wishing to track source changes to the
tree, maintaining a local (personal) copy of
the source on their own machine. The user will have to decide:
- The CVS server to use. There may be only one server or, for larger
projects, a number of mirror servers.
- Where the source module(s) will be kept on the local machine.
In our example, the OpenBSD
project, there are a large
number of servers to choose from. It's generally better to use a server that
is geographically closer since this tends to be faster and less of a strain
for the master server. Utilities such as
can be used to decide which host will be best to use. Secondly, the local
repository has to be stored somewhere. OpenBSD
as the default location for its
source tree (the “src” module), but this is largely arbitrary.
This example shows how a user initially checks out a copy of the source tree
from local mirror anoncvs.nl.openbsd.org:
$ cd /usr
$ cvs -d firstname.lastname@example.org:/cvs checkout -P src
In this case it was first necessary to add ourselves to the “wsrc”
group, since /usr/src
is writable only by
user “root” and/or group “wsrc”. The
option was necessary to tell
the location of the remote server. Note the “:/cvs” string
appended to the server's address: the path to the repository
be specified. Finally the
command was used to obtain a copy
of the module “src”.
Note that the above example simply checked out
-current: often different software versions are
available: use an identifier (tag
) to specify
which version to check out.
Thereafter the user is free to manipulate the source tree using the
utility itself. For example, the following would update (sync) the local copy
of “src” with the remote copy:
$ cd /usr/src
$ cvs -d email@example.com:/cvs update -Pd
General users may wish to use
simply to keep a copy of sources up to date with a development tree;
developers of software projects can also use
to make their own changes to a set of remote source files, and to view changes
made by other software developers.
for more information on the different commands available. See the entry for
for details on configuring
Software developers may wish to use
to manage their own software projects. Here we look at an example usage:
providing remote access to a small group of developers working on project
“foo”, located in
. First of all a
has to be created. A repository is
just the location of the group of files to be managed. Within the repository,
files may be organised into collections of files, called
, which are just logical groupings of
In our example, module “foo” is located at
is both the root directory
) of our repository and the name of our
If a set of source files already exist, possibly already under revision control,
they can be added to a repository using the
. This is a useful way of
adding modules to a pre-existing repository. In our example we are starting
from scratch, so the repository has to be initialised using the
# cd /cvs/projects
# cvs -d /cvs/projects init
This will create a default administrative directory,
, filled with files
concerned with the management of the repository.
Thereafter, access will have to be arranged for developers participating in the
project. This typically means providing SSH access via
for remote access, unless the development network is local.
The OpenCVS project is a -licensedBSD
rewrite of the
original Concurrent Versioning System written by Jean-Francois Brousseau. The
original CVS code was written in large parts by Dick Grune, Brian Berliner,
and Jeff Polk.
This CVS implementation does not fully conform to the GNU CVS version. In some
cases, this was done explicitly because GNU CVS has inconsistencies or
ambiguous behaviour. Some things have also been left out or modified to
enhance the overall security of the system.
Among other things, support for the pserver connection mechanism has been
dropped because of security issues with the authentication mechanism.