15.5.1.1. Setting up the password server with inetd

• Make sure there is an entry in /etc/services similar to the following:

  cvspserver 2401/tcp

• If you are not using tcpwrappers, place a line like this in /etc/inetd.conf:

  cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/usr/
  local/cvsroot pserver

• Or, if you are using tcpwrappers, use a line like this:

  cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs 
  --allow-root=/usr/local/cvsroot pserver

• Once these changes are in place, restart inetd (or send it the appropriate signal to cause it to reread inetd.conf).

15.5.3.1. The CVSROOT directory

Table 15-2. Filename pattern special constructions

CVS will perform a few important expansions in the contents of the administrative files before interpreting the results. First, the typical shell syntax for referring to a home directory is ~/, which expands to the home directory of the user running CVS, and ~user expands to the home directory of the specified user.

Table 15-3. Administrative file variables

To edit these files, check out the CVSROOT module from the repository, edit the files, and commit them back to the repository. You must commit the changes for them to affect CVS's behavior.

Table 15-4. CVSROOT files

Since the editinfo file is obsolete, use the $EDITOR environment variable (or the -e option) to specify the editor and the verifymsg file to specify an evaluator.

Each line of the taginfo file contains a filename pattern and a command line to execute when files with matching names are tagged.

15.5.3.2. The checkoutlist file

cvs commit: Rebuilding administrative file database

This informs you that the checked-out copy in the repository has been updated to reflect any changes just committed. As with any other module directory in the repository, the CVSROOT directory contains RCS (*,v) files that retain the history of the files. But to use the files, CVS needs a copy of the latest revision. So, when CVS prints this message, it is checking out the latest revisions of the administrative files.

If you have added files to the CVSROOT module (such as scripts to be called via entries in the loginfo file), you will need to list them in the checkoutlist file. This makes CVS treat them the same way as it treats the standard set of CVSROOT files.

Each line in this file consists of a filename and an optional error message that is displayed in case there is trouble checking out the file.

15.5.3.3. The commitinfo file

Aside from the usual filename-pattern syntax, there are two special patterns:

ALL

If this pattern is present in the file, all files are passed to the specified checking program. CVS then looks for a pattern that matches the name of each particular file and runs the additional checks found, if any.

DEFAULT

If this pattern is present in the file, all files for which there was no pattern match are sent to the specified checking program. The automatic match of every file to the ALL entry, if any, does not count as a match when determining whether or not to send the file to the DEFAULT checking program.

CVS constructs the command line for the checking program by appending the full path to the directory within the repository and the list of files being committed (this means you can specify the first few command-line arguments to the program, if necessary). If the checking program exits with a nonzero status, the commit is aborted.

The programs that run via this mechanism run on the server computer when a remote repository is used. Here is an example of a commitinfo file:

ALL $CVSROOT/CVSROOT/commit-ALL.pl
DEFAULT $CVSROOT/CVSROOT/commit-DEFAULT.pl
CVSROOT$ $CVSROOT/CVSROOT/commit-CVSROOT.pl

This example assumes you will create the script files in the CVSROOT module and add them to the checkoutlist file.

15.5.3.4. The config file

15.5.3.5. The cvsignore file

There is a slight difference between filename patterns in sh and CVS. Since the CVS patterns are not subject to variable interpolation, a pattern such as _$* (which is one of the patterns built into CVS) will match a file named _$foo but not one named _. But, if you present the same pattern to sh, the $* part will be interpolated resulting in an effective pattern of just _, which will then match the file _, but not _$foo. This becomes particularly important if you are writing your own utilities to work with CVS and you need to implement the same policy for ignoring files.

Table 15-5. Filename patterns for cvsignore

Again, diverging from the standards used by the rest of the administrative files, the cvsignore file does not support comments.

15.5.3.6. The cvswrappers file

15.5.3.7. The history file

A repository set up with cvs init automatically has a history file.

15.5.3.8. The loginfo file

Table 15-6. Special loginfo variables

If a percent sign (%) followed by the desired variable is placed after the command path, CVS inserts the corresponding information as a whitespace-separated list with one entry for each file, preceded by the repository path (as with commitinfo). There can be only one percent sign on the command line, so if you want information from more than one variable, place the variable names inside curly brackets: %{...}. In this case, each file-specific entry has one field for each variable, separated by commas. For example, the code %{sVv} expands into a list like this:

/usr/local/cvsrep/hello Makefile,1.1,1.2 hello.c,1.8,1.9

It can be helpful to send email notifications each time someone commits a file to the repository. Developers can monitor this stream of notices to determine when they should pull the latest development code into their private sandboxes. For example, consider a developer doing some preparatory work in his sandbox while he awaits stabilization and addition of another developer's new library. As soon as the new library is added and committed, email notification goes out, and the waiting developer sees that the code is ready to use. So, he runs cvs upd -d in the appropriate directory to pull in the new library code and then sets about integrating it with his work.

It is simple to set up this kind of notification. Just add a line like this to the CVSROOT/loginfo file:

DEFAULT mail -s %s [email protected]

Often, the email address is a mailing list, which has all the interested parties (developers or otherwise) on the distribution list. If you want to send messages to multiple email addresses, you can write a script to do that and have that script called via this file. Alternatively, you can use the log.pl program that comes as part of the CVS source distribution (located at /usr/local/src/cvs-1.11/contrib/log.pl, assuming CVS was unpacked into /usr/local/src). Instructions for its use are provided as comments in the file.

15.5.3.9. The modules file

Alias

Alias modules are defined by lines of the form:

module_name -a alias_module ...

Using an alias module name in a CVS command is equivalent to using its component modules (after the -a option) directly.

Regular

Regular modules are defined by lines of the form:

module_name [options] directory file ...

Checking out module_name results in the specified files from directory being checked out into a directory named module_name. The intervening directories (if any) are not reflected in the sandbox.

Ampersand

Ampersand modules are defined by lines of the form:

module_name [options] &other_module ...

Checking out such a module results in a directory named module_name, which in turn contains copies of the other_module modules.

Table 15-7. Module options

Alias modules provide alternative names for other modules or shortcuts for referring to collections or subdirectories of other modules. Alias module definitions function like macro definitions in that they cause commands to run as if the expanded list of modules and directories were on the command line. Alias modules do not cause the modules of their definition to be grouped together under the alias name (use ampersand modules for that). For example, the definition:

h -a hello

makes the name h a synonym for the hello module. This definition:

project -a library client server

allows you to check out all three modules of the project as a unit. If an entry in the definition of an alias module is preceded by an exclamation point (!), then the named directory is excluded from the module.

Regular modules allow you to create modules that are subsets of other modules. For example, the definition:

header library library.h

creates the header module, which consists of only the library.h file from the library module.

Ampersand modules are true logical modules. There are no top-level directories for them in the repository, but you can check them out to sandboxes, and directories with their names will then appear. The modules listed in the definition are below that directory. For example:

project &library &client &server

is almost the same as the alias module example given earlier, except that the submodules are checked out inside a subdirectory named project.

In this file, long definitions may be split across multiple lines by terminating all but the last line with backslashes (\).

15.5.3.10. The notify file

Each line of the notify file contains a filename pattern and a command line. CVS's notification mechanism uses the command line specified to perform notifications for files with names that match the corresponding pattern.

There is a single special-purpose variable, %s, that can appear in the command specification. When the command is executed, the name of the user to notify replaces the variable name. If the users administrative file exists, the usernames are looked up there, and the resulting values are used for %s instead. This allows emails to be sent to accounts other than those on the local machine. Details are sent to the notification program via standard input.

Typical usage of this feature is the single entry:

ALL mail %s -s "CVS notification"

In fact, this entry is present in the default notify file created when you run cvs init to create a repository (although it is initially commented out).

15.5.3.11. The passwd file

15.5.3.12. The rcsinfo file

The ALL and DEFAULT special patterns apply to this file.

15.5.3.13. The readers file

15.5.3.14. The taginfo file

The taginfo file is called with the tag, the operation being performed, the module directory name (relative to the repository root), and the filename and revision number for each affected file. The valid operations are add (for tag), del (for tag -d), and mov (for tag -F).

If the taginfo program returns a nonzero status, the tag or rtag command that caused its execution is aborted.

15.5.3.15. The users file

john:[email protected]
jane:[email protected]

15.5.3.16. The verifymsg file

The ALL special pattern is not supported for this file, although DEFAULT is. If more than one pattern matches, the first match is used.

15.5.3.17. The writers file

15.5.5.1. Importing code snapshots

For example, first unpack the distributions (this assumes they unpack to directories containing the version numbers):

$ tar xvzf foo-1.0.tar.gz
$ tar xvzf foo-1.1.tar.gz
$ tar xvzf foo-2.0.tar.gz

Next, make a copy of the first version, import it into the CVS repository, check it out to make a sandbox (since importing doesn't convert the source directory into a sandbox), and use cvs tag to give it a symbolic name reflecting the project version:

$ mkdir foo
$ cp -R -p foo-1.0/* foo
$ cd foo
$ cvs import -m 'Imported version 1.0' foo vendor start
$ cd ..
$ mv foo foo.bak
$ cvs checkout foo
$ cd foo
$ cvs tag foo-1_0
$ cd ..

Now, apply the differences between Version 1.0 and 1.1 to the sandbox, commit the changes, and create a tag:

$ diff -Naur foo-1.0 foo-1.1 | (cd foo; patch -Np1)
$ cd foo
$ cvs commit -m 'Imported version 1.1'
$ cvs tag foo-1_1
$ cd ..

Apply the differences between Version 1.1 and 2.0 to the sandbox, commit the changes, and create a tag:

$ diff -Naur foo-1.1 foo-2.0 | (cd foo; patch -Np1)
$ cd foo
$ cvs commit -m 'Imported version 2.0'
$ cvs tag foo-2_0

You can now use the log command to view the history of the files, browse past versions of the files, and continue development under version control.

15.5.5.2. Importing from RCS

Before beginning, make sure none of the files to be imported into CVS is locked by RCS. Then, create a new CVS repository and module (or a new module within an existing repository). Next, create directories in the CVS repository to mirror the project's directory structure. Finally, copy all the version files (,v) from the project (which may be in RCS subdirectories) into the appropriate directories in the repository (without RCS subdirectories).

For example, first move aside the directory under RCS control, create an empty directory to build the new CVS structure, import the directory, and then check it out to make a sandbox:

$ mv foo foo-rcs
$ mkdir foo
$ cd foo
$ cvs import -m 'New empty project' foo vendor start
$ cd ..
$ mv foo foo.bak
$ cvs checkout foo

Next, make directories and add them to the repository to match the structure in the RCS project:

$ cd foo
$ mkdir dir
$ cvs add dir
$ cd ..

Now, copy the ,v files from the RCS project into the repository for the CVS project:

$ cp -p foo-rcs/*,v $CVSROOT/foo
$ cp -p foo-rcs/dir/*,v $CVSROOT/foo/dir

Finally, issue the cvs update command in the sandbox directory to bring in the latest versions of all the files:

$ cd foo
$ cvs upd

15.5.5.3. Importing from SCCS

15.5.5.4. Importing from PVCS