Page 1118
|
contain either other module names or paths. When you use paths in aliases,cvs 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 one of the source repositories. 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. The checkout command creates a subdirectory for each such module in your working directory. New in cvs 1.3; avoid this feature if sharing module definitions with older versions of cvs. | |
|
Finally, you can use one or more of the following options in module definitions: _d name names the working directory something other than the module name. This option is new in cvs 1.3; avoid this feature if sharing module definitions with older versions of cvs. _i prog allows you to 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 allows you to specify a program prog to run whenever files in a module are checked out. prog runs with a single argument, the module name. _e prog allows you to specify a program prog to run whenever files in a module are exported. prog runs with a single argument, the module name. _t prog allows you to specify a program prog to run whenever files in a module are tagged. prog runs with two arguments: the module name and the symbolic tag specified to rtag. _u prog allows you to 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. | |
| commitinfo, loginfo, rcsinfo, editinfo |
These files all specify programs to call at different points in the cvs commit process. They have a common structure. Each line is a pair of fields: a regular expression, separated by whitespace from a filename or command-line template. Whenever one of the regular expression matches a directory name in the repository, the rest of the line is used. If the line begins with a # character, the entire line is considered a comment and is ignored. Whitespace between the fields is also ignored. For loginfo, the rest of the line is a command-line template to execute. The templates can include not only a program name, but also whatever list of arguments you want. If you write %s somewhere on the argument list, cvs supplies, at that point, the list of files affected by the commit. The first entry in the list is the relative path within the source repository where the change is being made. The remaining arguments list the files that are being modified, added, or removed by this commit invocation. For taginfo, the rest of the line is a command-line template to execute. The arguments passed to the command are, |