cvsEnhancements is a collection of useful scripts and patches to
flesh out a CVS installation with various features. For more
information about a particular script, see the comments in that script.
Front end, user-callable scripts
- General purpose script that lists
revision-controlled files in your sandbox under your
current directory. It has an interface similar to
"git ls-files", only for CVS.
- For code reviews: A perl script that reads
in output from "cvs diff" specifiing the difference between any
repository version and the sandbox in the current
directory, and outputs an easy-to-browse
HTML site showing the differences. Generates one web page
per changed file, consisting of a well formatted table
showing differences. Also works with "git diff" in a git sandbox.
- A script for syncronizing
changes across multiple copies of a CVS working
area. This is especially useful for trying out changes
on multiple architecures before committing those changes.
- cvsAdd, cvsCommit, cvsOut,
- Higher level
operations related to cvsSync. (These are actually symlinks to
makeLinks script can be used to create these links.
scripts to use for
quickly mounting/unmounting Windows NT drives.
force_umount should be suid-root.
The nmount and numount scripts use smbmount and smbumount,
so smbmount/smbumount should be installed suid-root.
- A script to tell you who has what
RCS locks in a CVS repository.
- A general purpose tool for maintaining the
CVS pserver "passwd", "writers", and "users" files. It should
be installed suid-root.
- A script for rebinding a sandbox
to a repository.
Back end, server-called scripts
- A script to indirectly look up valid
CVSROOTs and invoke "cvs pserver". Put this in /etc/inetd.conf
instead of cvs itself.
- A fairly generic generic logging
script to invoke from
loginfo; it logs to both a full featured log and a simple
one-line-per-file lightweight log. It can also
send email about commits to configurable lists of users.
- A relatively fancy notify script that sends
mail to both the watching user and the user that did
the action that was watched for. Mainly intended to
let both users know if they are editting the same
file. I would prefer to send a message directly,
but that would probably require source modifications to
avoid messing up the remote access communications protocol.
- A web-callable wrapper around
- A generic program to group multiple mail
messages sent to a user in a short period of time into one
message. The other scripts use this script, if available.
- A commitinfo script to verify compliance
with some trivial-to-test-for coding standards.
- Goes with commitCheck.
- Goes with commitCheck.
- Advisory Locks (external page)
- [OBSOLETE: A
heavily modified variation of this patch has been incorporated
into cvs 1.12.x.] My Version of the
Advisory Lock Patch. For advisory locks, be sure to download the
latest dated version (editCheck-25feb2002.diff at the time I
was writing this). But the first, no-date version
(editCheck.diff) also includes a socket record/playback
testing tool that might be interesting on it's own.
- A patch to cause "cvs update"
to print out sticky option information.
- [OBSOLETE: You can just use "$USER"
in the *info config files to pass the pserver username in on
the command line.] A patch to cause "cvs pserver" to
store the authenticated user name (as opposed to the host
user name) in the environment variable "CVS_AUTH_USER".
doLog uses this value, if it is available.
Setting things up
In my environment, I have CVS running in pserver mode. My
doesn't invoke pserver directly. Instead, it invokes the cvsPserver
script. cvsPserver parses the /etc/cvsRepositories
file, and then invokes "cvs pserver" with the appropriate "--allow-root"
options. Generally, we always go through the pserver, even when
running cvs on the local machine.
I have two special users for CVS: cvsadmin and cvsuser.
In /etc/passwd, the entries look like this (group
18 is called 'cvs'):
cvsadmin:*:407:18:CVS admin server:/home/cvs:/bin/false
cvsadmin is the owner of security-sensitive configuration
files. It needs to be as carefully controlled as root, because
if you can become cvsadmin, you can trivially become root as well.
When I need to be cvsadmin, (e.g. to edit configuration files),
I go through root:
I generally keep the CVSROOT directory for each repository checked out
somewhere under /home/cvs, so that I can easily edit the
- su -s /bin/bash - cvsadmin
I have the cvs passwd file configured to map
everyone to "cvsuser" (and in fact I disable access
for anyone not in cvs's passwd file by setting SystemAuth=no in
I also have a group "cvs" which allows me to give cvsadmin, cvsroot,
and possibly trusted power users full read access to everything
under /home/cvsadmin, while preventing anyone else from accessing it
directly. Note that security sensitive files (CVSROOT and all its parent
directories) have to be read-only for everyone except "cvsadmin".
If you want to enforce everyone going through pserver, make CVSROOT
mode 770, and don't put anyone except cvsadmin and cvsroot in the cvs
Sourceforge has a lot of projects related to CVS. Some projects
that may provide capabilities similar (perhaps even superior) to
some of the scripts in cvsEnhancements include:
There is actually a fairly large list of CVS-related projects
on sourceforge; try running a search for "CVS".
Also, you can check a (relatively) official list of
CVS addons by clicking
Currently, the only author of cvsEnhancments is Matthew Ogilvie,
who can be reached at
mmogilvi <at> users.sourceforge.net or
his home page.