vc module provides an interface to the Concurrent
Versions System (CVS).
At this point we are all used to working collaboratively on site development, and to using CVS for managing the code base as the site is programmed. But what about modules that provide access to site content or software management tools? Do we give up version control in this case? Do we have to rewrite the machinery of a system like CVS? Absolutely not!
vc module provides a simple interface to CVS that
can be used by any module to add version control capabilities. It
also provides procedures to obtain version control information for any
file in the project, i.e. to display additional information in the
page footer or for integration with bug tracking systems. Current
modules that use
vc include the package manager, the file manager, and the manual system.
vcmodule does not have any user pages, just a set of procs that allow you to access the version control system. Every proc takes the full pathname of a file to operate on. The public API consists of the following (all are direct analogies to the corresponding CVS command):
- vc_add path
- vc_log path
- vc_status path
- vc_remove path
- vc_commit path message
There are also a number of procs that simply grab information from CVS either by exec-ing the executable or by reading the appropriate version control information from the file system:
- vc_fetch_repository path
- vc_fetch_root path
- vc_fetch_status path
- vc_fetch_summary path
- vc_fetch_date path
- vc_fetch_revision path
An individual query can be relatively expensive, particularly if
CVS has to go over the network to access information from a remote
repository. Therefore, all information managed by the
module is cached within the server based on the modification time of
the corresponding file.
To use the
vc module you will need to set the
[ns/server/yourservername/acs/vc] ; Location of the CVS repository. If the repository is on a remote ; host, you need to make sure that CVS can connect without being ; prompted for a password. CVSROOT=/cvsweb ; Location of the CVS executable CvsPath=/usr/local/bin/cvs
CVSROOT is exactly the same as the
environment variable used by CVS. The parameter
specifies the location of the CVS executable. If you are running a
chrooted server then the CVS executable must be located within the
restricted path of the server.
vc module will happily talk across the network to a
remote repository, e.g.
allow you to access the repository
hostname. The only connection methods currently
supported are pserver
and ext using
secure shell as the connection agent (strongly recommended). For this
to work the user nsadmin (or whatever user account the
AOLserver binary runs as) must be able to connect to the repository
host without being prompted for a password.
This is easy to set up and relatively secure using ssh with RSA authentication. We'll assume the server runs as nsadmin.
ssh-keygenwith no passphrase to generate
~nsadmin/.ssh/identity.pubto the repository host and append it to
authorized_keysfile has its permissions set to 400.
ssh -v nsadmin@repository-host. If you fail to connect automatically, check the log output for some explanation as to why the authentication failed.
cvs -n updatefrom the top-level directory of your project while logged in as nsadmin to make sure that CVS can connect to the repository host correctly.
As a final note, if you're running a chrooted server then the
ssh binary will also need to be in the restricted path.
Might be nice to integerate with things like the ticket tracker or general comments on a page.
As written these procs are tied specifically to CVS, but they could be extended to work with RCS or SCCS repositories, or any other revision control system we might adopt in the future.