Resources for developing CVS or CVS-related software

We like to see people working on CVS or software that works together with CVS. While we get particularly excited about freely redistributable software, because we have seen the power of collaborative software development, this also applies to traditionally licensed commercial software.

This page contains resources for use in developing CVS or CVS-related software.

Logos

We have a page of CVS Logos which we encourage you to use in any CVS-related context. For example, a CVS-related web page or the "About fooCVS" box on a CVS-related program with a graphical user interface.

Hosting for Web/FTP/CVS/bug-tracking/&c

Once you've written some CVS-related software, you may want to make it available to the public. It shouldn't be hard to find a way to do this. A few places to start (at least for web and FTP hosting) are your Internet Service Provider, Linuxbox, XNOT (financial arrangements kind of complicated; includes hosting CVS, bug-tracking and more), Linux Support Line, and SEUL (end-user and educational).

Or another option is to ask a free software project which seems related. For example, GNOME, KDE, tux.org, Software in the Public Interest, and others have been known to host projects, at least those with some connection with their own project (but you'd have to ask them, not us, regarding your specific project).

Documented Interfaces

Most of CVS's interfaces have at least some documentation (keep reading for details).

For a larger list of interfaces between version control systems and clients such as development environments or scripts, which may or may not be (yet) implemented in CVS, see our Version Control Interfaces page.

If you are trying to implement these interfaces, and have questions, please ask on bug-cvs. Most likely someone will be interested in clarifying the documentation, or maybe even extending the interfaces. No promises, but often what holds back cleaning up interfaces is the lack of someone who would actually use the cleanups (to see that they do the right thing, to provide for testing them with new versions of CVS, and so on). For example, here is an unofficial patch to use the tagged text features of the remote protocol in more cases.

Here is an unofficial patch to give clients fuller access to the version history. Trying to get a list of the files in the repository is a common issue.

We have a page on implementing CVS-related programs in various languages.

CVS Client/server protocol

The protocol is documented in doc/cvsclient.texi in the CVS source distribution. For the most part it puts the intelligence on the server. It also is designed, to a fair extent, for low-bandwidth connections and connections which might not be up all the time. Not that any of this is written in stone as the protocol and its implementations evolve, but we mention these design features just to give a general idea of what sort of protocol it is.

As far as we know the server has only been implemented once. It would be nice to see additional implementations.

The client side has been implemented much more. Here are some of the implementations:

• The command line client, which is part of the CVS source distribution, is written in C and is a full-featured client. Although the code is hopefully more or less readable, it perhaps is not the first place to turn if you are learning the protocol (partly because it is so full-featured).
• MacCVSClient implements a CVS client in C++. It includes the basic functionality but no bells and whistles.
• jCVS implements a CVS client in Java. The parts of the code which talk to the server are broken out into classes which are intended to be usable in other contexts (such as special-purpose clients), or so is our impression.
• A special-purpose client in perl (or your favorite scripting language) isn't very hard and is often the cleanest way to control CVS from a script. For example, we have some example scripts which demonstrate how to operate on the repository without actually creating a working directory: cvs annotate and cvs admin -t.

Working directory formats

The way that files are stored in the CVS working directories (for example the format of the CVS/Entries and CVS/Tag files) is documented in recent versions of the Cederqvist manual. Affected programs include the CVS client, the VC package for emacs, jCVS, and a vast number of special-purpose scripts.

Repository formats

The way that files are stored in the CVS repository is documented in recent versions of the Cederqvist manual. Programs that are affected by this include the CVS server, cvsweb, CVSup (the mirroring tool from FreeBSD), and a vast number of special-purpose scripts.

Note that running RCS commands to update the CVS repository has the potential for problems, because the programs use different locking mechanisms. CVS's mechanism is documented in the Cederqvist and involves lock files with names starting with #cvs. RCS's mechanism involves lock files with names like ,foo.pl, and is not supported by CVS. To use the CVS convention in scripts and other tools, see the cvslock program from Thomas Roessler.

The RCS file format itself is documented in the rcsfile(5) manpage in the RCS distribution, and the file doc/RCSFILES in the CVS source distribution. Programs which can at least read this format include CVS, RCS, and rinfo.