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
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,
well look at a user wishing to track source changes to the
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
project, there are a large number of servers to choose from.
Its 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.
as the default location for its source tree
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
is writable only by user
option was necessary to tell
the location of the remote server.
string appended to the servers address:
the path to the repository
command was used to obtain a copy of the module
Note that the above example simply checked out
.Ox Ns -current :
often different software versions are available:
use an identifier
to specify which version to check out.
Thereafter the user is free to manipulate the source tree
For example, the following would update (sync) the local copy of
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
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,
which are just logical groupings of files.
In our example, module
is located at
is both the root directory
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
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.