Separating Metadata in CVS

CVS does not separate the "metadata" from the actual revision history; it stores them both in the RCS files. Metadata means tags and header information such as the number of the head revision.

The two biggest problems that separating metadata might solve are (1) "cvs tag" on a large repository is horribly slow, and (2) separating metadata could also probably make CVS's locking much less in the way (see comment in do_recursion about "two-pass design").

Here is a CVS 1.10 patch for a simple form of separated metadata and an older version of the same patch with commentary. Along similar lines, here is one to remove the tags from the RCS files.

Here is a set of ideas concerning an interface which might interface CVS to a separated metadata backend.

On the other hand, separated metadata introduces the possibility of having the metadata inconsistent with the RCS files and may make it harder for a CVS administrator to see exactly what is in the repository. This would break programs which depend on the current repository format such as CVSup, CVSweb or old versions of CVS. There would also be the need for a new feature to allow one to export/import RCS files from CVS (with all the tags and everything). For all these reasons, separated metadata, if would need to be an option in CVSROOT/config rather than being always enabled).

Here are a few ideas on how to solve/ameliorate the problems in other ways:

• The cvs tag problem could be solved with some analogue to a logging file system in which the revision numbers to be tagged could be written to a log and then migrated over to the RCS files at one's leisure. This is kind of clean but might be a more elaborate solution than is justified.
• Something else which may help is to reserve space in the RCS files and then CVS tag can overwrite just that portion of each RCS file rather than the entire RCS file.
• Implementing the two-pass design in recurse.c probably could be done with some fancier locking. For example, two read/write locks (compared with the existing CVS which has one such lock). One lock is for changes which affect existing revisions (such as "cvs admin -o", "cvs admin -m", probably moving a tag, &c). All readers would get this lock but only a few writers would need it. The other lock would be for ordinary changes which merely add additional revisions, tags, &c. Readers would only need this lock in the first pass (might need to think a little bit about making sure that the second pass can cope, but atomic renames of RCS files and such should mostly deal with it - might need to warn against enabling FancyLocks for NFS, not sure). Would need to think very carefully about compatibility, as compatibility bugs would be hard to find.

The issue of separated metadata is item #194 in the TODO file in the CVS distribution (although the information/ideas there are also incorporated into this page).

Additional Thoughts on Locks

CVS's locking strategy is somewhat related to the issue of how metadata is handled; this section is about CVS locks specifically. Also see the comment at the start of src/lock.c in the CVS source distribution.

This patch adds an option to CVS to turn off the readlocks which CVS creates in the repository. This patch is not recommended, but it is here because this kind of thing tends to get suggested a lot. For more information on what those readlocks are for (and, by extension, the consequences of disabling them), see the comment at the start of src/lock.c.