Running Arbitrary Scripts Under CVS

Hook Files and Their Roles

When you install CVS on a server, the repository comes with a special directory called CVSROOT. Inside that directory, five files sit quietly, waiting for you to put code in them: commitinfo, loginfo, verifymsg, rcsinfo, and taginfo. They do not look like ordinary configuration files. Instead, each of them is a dispatcher for scripts that run automatically at key moments during a CVS operation. Understanding their timing and purpose is the first step to harnessing CVS hooks effectively.

Whenever a user checks in new revisions with cvs commit, the system calls these files in a precise order. For a commit, CVS executes commitinfo before the files are written to the repository, verifymsg after the user has typed the log message but before the files become permanent, and loginfo after the repository is updated. These hooks give you three opportunities to intervene: to reject a commit that violates a rule, to modify the log message on the fly, or to publish the commit data elsewhere.

Tagging introduces a different set of hooks. When a developer runs cvs tag or cvs rtag, CVS invokes taginfo before the tags are added, moved, or deleted. The file provides a chance to validate the tag name, adjust the target revision, or log the action in a separate system.

The rcsinfo file is a bit different. It does not run a script. Instead, it points to a template file that CVS opens in the editor when a developer prepares a commit message. This template can pre-fill placeholders that the developer later edits. Because the template is read when the editor starts, you can use it to enforce a consistent structure across all log messages.

Although the names of these files suggest a linear flow, in practice they are independent dispatchers. The rules you write in commitinfo apply only to commit time; taginfo never sees a commit event, and vice versa. This separation keeps the hooks modular and easier to reason about. If you need to change the validation logic for commits, edit only commitinfo and leave the other files untouched. If you later add a new type of operation, you can create a new dispatcher file without touching the existing ones.

Because these files are read and executed on the server side, they run under the permissions of the CVS process. This has two practical implications. First, any user who has write access to CVSROOT can modify the hooks and potentially break the workflow for everyone else. Second, because the hooks run on the server, they can access repository internals that client-side scripts cannot. Knowing this, you should keep the hook files under strict version control and restrict write permissions to a small group of administrators.

In the next section we will explain the syntax that governs how CVS matches a directory to a rule inside one of these files. The pattern language is a small regular‑expression subset, and understanding it is key to writing robust scripts that trigger exactly where you intend them to.

Syntax, Patterns, and Action Templates

Each of the five hook files follows the same rule format: a regular‑expression pattern, a space, and then an action. The pattern is matched against the relative path of a directory within the repository, starting at the root of the repository. The action is a shell command that receives the matching directory and, in some cases, additional arguments supplied by CVS. For example, a rule might look like this:

In this line, the pattern ^src(/|$) matches any directory whose path starts with src and is either followed by a slash (indicating a subdirectory) or ends immediately (the root of src). When a commit touches that directory, CVS will invoke /usr/local/cvs/scripts/check_style. The script receives the directory name and, depending on the hook, may also get a list of files or a log message.

Two special patterns make rule sets more flexible. The pattern ALL matches every directory in the repository. It is useful for hooks that should run globally, such as a script that logs all commits to an audit trail. The pattern DEFAULT is a fallback that applies only if no other pattern (except ALL) matches a given directory. A typical rule set might include an ALL pattern that calls a generic script, and a DEFAULT pattern that performs a minimal action or nothing at all.

When CVS finds a rule that matches, it stops looking for further matches in that file. This means that the order of rules matters only if you rely on ALL or DEFAULT to catch directories that would otherwise be ignored. In most configurations, you’ll place specific rules first and the generic ALL rule at the end.

The action part of a rule is a shell command line. The command may include arguments that are constants, file names, or placeholders that CVS expands. For example, the loginfo hook uses an action of the form:

Here, the placeholder %% will be replaced by a format string that expands to a list of files and revisions affected by the commit. The final command line might become:

Scripts can read from standard input, write to standard output, or use environment variables, but the only guaranteed input method is stdin. The command line parameters are appended after the script name by CVS. The exact parameters depend on the hook type. For example, commitinfo receives the relative directory and a list of files that will be committed; verifymsg receives the path to a temporary file that contains the log message; and taginfo receives a string that includes the tag name, the operation (add/mov/del), the repository path, and a list of file–revision pairs.

Lines that start with a hash (#) are comments and are ignored by CVS. Comments are useful for documenting the purpose of a rule or the meaning of its arguments. It is a good practice to add a comment above every rule you write, especially in shared repositories where multiple administrators may touch the files.

Because the pattern language is a subset of regular expressions, you can use anchors, character classes, and quantifiers. However, CVS does not support backreferences or advanced features like lookaheads. For most use cases, the simple patterns shown above suffice. If you need more elaborate matching, you can call an external script that performs its own pattern matching and decide whether to proceed.

Once you grasp how patterns map directories to actions, you can begin to assemble hooks that enforce coding standards, audit changes, or integrate CVS with other tools. The next sections will walk through how to use each hook type for common tasks.

Commit‑Time Hooks: commitinfo and verifymsg

The commitinfo hook fires before CVS writes any new revisions to the repository. Its purpose is to allow you to validate the set of files about to be committed or to impose a lock on the repository for exclusive development. Because the hook runs in a context where the repository is still writable, you can examine the exact set of files that the user has requested to commit.

When the hook runs, CVS passes two arguments: the relative path of the directory that contains the files, and a space‑separated list of all files that will be committed in that directory. The script may inspect each file, run a linter, or check that the file names match a particular convention. If the script exits with a non‑zero status code, CVS aborts the entire commit operation. The user receives an error message and can adjust the commit accordingly.

Because commitinfo operates on a per‑directory basis, a single repository can have multiple directories with different rules. For example, you might allow anyone to commit to docs/ but restrict src/ to members of the core team. A rule for src/ would run a script that verifies the user’s group membership before allowing the commit. In practice, the script might look up the user’s UID in a database and compare it against a list of permitted IDs.

One nuance to keep in mind is that commitinfo receives a temporary copy of each file that will be committed. The script sees the file content in a directory called $TMPDIR (or a similar temporary location). If the script tries to modify a file, those changes are discarded once the hook finishes. This behavior protects the repository from accidental or malicious modifications, but it also means that commitinfo is read‑only with respect to the actual files. If you need to write a file during a commit, you must do so via a separate process that runs after commitinfo has finished, such as loginfo

The verifymsg hook gives you a second chance to scrutinize or alter the commit log message. After a user enters a message and before the commit proceeds, CVS creates a temporary file containing that message and passes its path as an argument to verifymsg. The script can then read the message from standard input or from the file path. If the script exits with a non‑zero status, the commit aborts.