Triggers and Logging in CVS

This page, part of Cyclic's Development of CVS pages, is about the various features in CVS, existing or future, which log CVS operations and/or allow one to have the CVS server run some kind of plug-in at various points (the latter functionality often being called triggers).

The summary regarding current features is that there are quite a few: *info files, CVSROOT/history, &c.

The summary regarding future visions is that it should be possible to design a new interface to triggers/logging which should be much cleaner than the status quo and also more powerful. Here are some CustomLog ideas which focus on logging. The idea with triggers is that one key part of the job - defining the events to be logged/triggered, and the information which can be logged, or passed to a trigger - is the same for logging as for triggers.

One design goal: make the information passed to triggers as orthogonal as possible. For example, with the status quo, the log message is passed to the loginfo and verifymsg triggers but not to the notify trigger. If the interface works by setting a bunch of environment variables, rather than a mishmash of standard input and command line arguments, providing orthogonality should be fairly clean.

One future direction that periodically gets suggested is to embed some language into CVS. This seems to have few advantages, as calling triggers is not a performance-critical operation (as far as I know, people are welcome to dispute this provide they bring some benchmark/profile data with them). Even if performance ends up being a problem, adopting a solution analogous to FastCGI, or if necessary a dlopen() plug-in interface, would be preferable to hardcoding the choice of scripting language.

Server-side plug-ins (existing *info interfaces)

CVS currently supports various plug-ins on the server-side via the administrative files (loginfo and friends). The interface is quite ugly and has gotten uglier with time. Here is some discussion, which also has a patch and discussion of one specific issue: what $USER gets set to. And here is another similar patch.

Here is an idea/patch to pass the process identification of CVS to the administrative file.

This patch lets commitinfo know what branch the commit would be to.

If you set up the rcsinfo file and then try to run "cvs export" with the client/server CVS, it is reported not to work.

Here are some test cases for rcsinfo.

This patch concerns blank lines in the CVSROOT/checkoutlist file.

In various cases the existing interfaces will try to pass too much information on the command line (exceeding operating system ARG_MAX limitations). The best solution, perhaps, will be to pass such information on standard input. Here is a patch to invoke the script several times (similar to xargs; for loginfo). Here's a patch to use standard input in certain cases (for commitinfo).

cvs history (one of the existing logging interfaces)

Bunch of items here:

• A patch regarding the -m option to "cvs history" and client/server CVS.
• TODO #155
• See comments in cvs.texinfo
• See the CustomLog ideas, above, which would be a replacement for the cvs history feature.
• Some gripes about the documentation.
• Certain record types don't get written to the history file. Also, "cvs tag" doesn't write anything to the history file, just "cvs rtag" (workaround: use taginfo).
• Core dumps in cvs history -a -T.
• The output from "cvs history" does not include the year, which makes it inconvenient to use if history spans more than one year.
• A patch/discussion concerning what CVS can do if the history file is not writable.
• Some patches from John Cavanaugh: select history records between two dates, rather than just since a single date, reduce gratuitous memory consumption by "cvs history", or a more recent patch which combines the two.
• The -l global option turns off logging to the history file, but it doesn't turn off the check for whether the history file is writeable (main.c).

See why there is some sentiment in favor of totally redesigning the history feature rather than trying to fix it?

CVSROOT/users and CVSROOT/notify

When looking up a user in CVSROOT/users, CVS doesn't strip off the newline. Here is a report and a fix.

Another item with CVSROOT/users is that presumably it should be generated automatically when checked in (mkmodules.c:filelist), or at least the documentation should suggest adding it to checkoutlist (presumably the former is better). Although when I implemented CVSROOT/user I had in mind having it be just in the repository like CVSROOT/passwd, I don't see any reason why that is necessary.

Of course, need test cases for CVSROOT/users (and notification in general; the easiest way to deal with multiple users is probably as in reserved-9 to reserved-16, that is to munge the CVS repository as if another user had done something).

Here's a patch to pass more information to the notify script.

Transforming data

Related to triggers is the idea of transforming data on its way in and out of CVS. See our -t/-f wrappers page for further discussion of the issues (both in terms of one existing solution, which adds -t and -f options to the wrappers file, and in terms of how the problem in general might be addressed).

Analysis and reporting tools

There are a number of tools to take the data which CVS can provide, and munge it in various ways. One of them is cvs2cl, which takes the output from "cvs log" and produces a ChangeLog.

Also see the CVS output page which mainly concerns "cvs log", "cvs status", and other existing ways of getting data out of CVS.