Go to the previous, next section.

The modules file

The `modules' file records your definitions of names for collections of source code. CVS will use these definitions if you create a file with the right format in `$CVSROOT/CVSROOT/modules,v'. The mkmodules(1) command should be run whenever the modules file changes, so that the appropriate files can be generated (depending on how you have configured CVS operation).

To allow convenient editing of the `modules' file itself, the file should include an entry like the following (where localbin represents the directory where your site installs programs like mkmodules(1)):

modules    -i /localbin/mkmodules CVSROOT modules

This defines the name `modules' as the module name for the file itself, so that you can use

$ cvs checkout modules

to get a copy of the file that you can edit. You should define similar module entries for the other configuration files described in this appendix, except `history').

The `modules' file may contain blank lines and comments (lines beginning with `#') as well as module definitions. Long lines can be continued on the next line by specifying a backslash (`\') as the last character on the line.

A module definition is a single line of the `modules' file, in either of two formats. In both cases, mname represents the symbolic module name, and the remainder of the line is its definition.

mname -a aliases...

This represents the simplest way of defining a module mname. The `-a' flags the definition as a simple alias: CVS will treat any use of mname (as a command argument) as if the list of names aliases had been specified instead. aliases may contain either other module names or paths. When you use paths in aliases, checkout creates all intermediate directories in the working directory, just as if the path had been specified explicitly in the CVS arguments.

mname [ options ] dir [ files... ] [ &module... ]

In the simplest case, this form of module definition reduces to `mname dir'. This defines all the files in directory dir as module mname. dir is a relative path (from $CVSROOT) to a directory of source in the source repository. In this case, on checkout, a single directory called mname is created as a working directory; no intermediate directory levels are used by default, even if dir was a path involving several directory levels.

By explicitly specifying files in the module definition after dir, you can select particular files from directory dir. The sample definition for `modules' is an example of a module defined with a single file from a particular directory. Here is another example:

m4test  unsupported/gnu/m4 foreach.m4 forloop.m4

With this definition, executing `cvs checkout m4test' will create a single working directory `m4test' containing the two files listed, which both come from a common directory several levels deep in the CVS source repository.

A module definition can refer to other modules by including `&module' in its definition. checkout creates a subdirectory for each such module, in your working directory.

-d name

Name the working directory something other than the module name.

-i prog

Specify a program prog to run whenever files in a module are committed. prog runs with a single argument, the full pathname of the affected directory in a source repository. The `commitinfo', `loginfo', and `editinfo' files provide other ways to call a program on commit.

-o prog

Specify a program prog to run whenever files in a module are checked out. prog runs with a single argument, the module name.

-s status

Assign a status to the module. When the module file is printed with `cvs checkout -s' the modules are sorted according to primarily module status, and secondarily according to the module name. This option has no other meaning. You can use this option for several things besides status: for instance, list the person that is responsible for this module.

-t prog

Specify a program prog to run whenever files in a module are tagged with rtag. prog runs with two arguments: the module name and the symbolic tag specified to rtag. There is no way to specify a program to run when tag is executed.

-u prog

Specify a program prog to run whenever `cvs update' is executed from the top-level directory of the checked-out module. prog runs with a single argument, the full path to the source repository for this module.

Go to the previous, next section.