CVSINTRO(7) BSD Miscellaneous Information Manual CVSINTRO(7)NAMEcvsintro — introduction to Concurrent Versioning System
DESCRIPTION
Concurrent Versions System is a popular open source version control sys‐
tem. 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 well.
This document provides an introduction to using OpenCVS to manage reposi‐
tories. It will first cover some of the aspects of using and managing
CVS and, where appropriate, explain the main differences between OpenCVS
and other distributions.
USING CVS TO TRACK SOURCE CHANGES
One of the most common uses of cvs(1) is to track changes to a collection
of source files (a module) 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 OpenBSD 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 geographi‐
cally closer since this tends to be faster and less of a strain for the
master server. Utilities such as ping(8) and traceroute(8) can be used
to decide which host will be best to use. Secondly, the local repository
has to be stored somewhere. OpenBSD uses /usr/src as the default loca‐
tion for its source tree (the “src” module), but this is largely arbi‐
trary.
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 anoncvs@anoncvs.nl.openbsd.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
-d option was necessary to tell cvs(1) the location of the remote server.
Note the “:/cvs” string appended to the server's address: the path to the
repository must be specified. Finally the checkout command was used to
obtain a copy of the module “src”.
Note that the above example simply checked out OpenBSD-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
cvs(1) utility itself. For example, the following would update (sync)
the local copy of “src” with the remote copy:
$ cd /usr/src
$ cvs -d anoncvs@anoncvs.nl.openbsd.org:/cvs update -Pd
General users may wish to use cvs(1) simply to keep a copy of sources up
to date with a development tree; developers of software projects can also
use cvs(1) to make their own changes to a set of remote source files, and
to view changes made by other software developers.
See cvs(1) for more information on the different commands available. See
the entry for $HOME/.cvsrc in cvs(5) for details on configuring cvs(1)
itself.
USING CVS TO MANAGE A REPOSITORY
Software developers may wish to use cvs(1) 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
/cvs/projects. First of all a repository has to be created. A reposi‐
tory is just the location of the group of files to be managed. Within
the repository, files may be organised into collections of files, called
modules, which are just logical groupings of files.
In our example, module “foo” is located at /cvs/projects/foo on machine
“cvs.example.org”. Therefore /cvs/projects is both the root directory
($CVSROOT) of our repository and the name of our repository.
If a set of source files already exist, possibly already under revision
control, they can be added to a repository using the cvs(1) command
import. This is a useful way of adding modules to a pre-existing reposi‐
tory. In our example we are starting from scratch, so the repository has
to be initialised using the init command:
# cd /cvs/projects
# cvs -d /cvs/projects init
This will create a default administrative directory, $CVSROOT/CVSROOT,
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 sshd(8)
for remote access, unless the development network is local.
SEE ALSOcvs(1), rcs(1), cvs(5), sshd(8)HISTORY
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.
AUTHORS
Jean-Francois Brousseau
CAVEATS
This CVS implementation does not fully conform to the GNU CVS version.
In some cases, this was done explicitly because GNU CVS has inconsisten‐
cies or ambiguous behaviour. Some things have also been left out or mod‐
ified 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.
BSD April 23, 2024 BSD
