# cvs(5) - man - phpMan [cvs(5)](https://www.chedong.com/phpMan.php/man/cvs/5/markdown) File Formats Manual [cvs(5)](https://www.chedong.com/phpMan.php/man/cvs/5/markdown) ## NAME cvs - Concurrent Versions System support files ## NOTE This documentation may no longer be up to date. Please consult the Cederqvist (CVS Manual) as specified in [**cvs**(**1**)](https://www.chedong.com/phpMan.php/man/cvs/1/markdown). ## SYNOPSIS ### $CVSROOT/CVSROOT/commitinfo,v ### $CVSROOT/CVSROOT/cvsignore,v ### $CVSROOT/CVSROOT/cvswrappers,v ### $CVSROOT/CVSROOT/editinfo,v ### $CVSROOT/CVSROOT/history ### $CVSROOT/CVSROOT/loginfo,v ### $CVSROOT/CVSROOT/modules,v ### $CVSROOT/CVSROOT/rcsinfo,v ### $CVSROOT/CVSROOT/taginfo,v ## DESCRIPTION **cvs** is a system for providing source control to hierarchical collections of source directo‐ ries. Commands and procedures for using **cvs** are described in [**cvs**(**1**)](https://www.chedong.com/phpMan.php/man/cvs/1/markdown). **cvs** manages _source_ _repositories_, the directories containing master copies of the revision- controlled files, by copying particular revisions of the files to (and modifications back from) developers' private _working_ _directories_. In terms of file structure, each individual source repository is an immediate subdirectory of **$CVSROOT**. The files described here are supporting files; they do not have to exist for **cvs** to operate, but they allow you to make **cvs** operation more flexible. You can use the `modules' file to define symbolic names for collections of source maintained with **cvs**. If there is no `modules' file, developers must specify complete path names (abso‐ lute, or relative to **$CVSROOT**) for the files they wish to manage with **cvs** commands. You can use the `commitinfo' file to define programs to execute whenever `**cvs** **commit**' is about to execute. These programs are used for ``pre-commit'' checking to verify that the modified, added, and removed files are really ready to be committed. Some uses for this check might be to turn off a portion (or all) of the source repository from a particular per‐ son or group. Or, perhaps, to verify that the changed files conform to the site's standards for coding practice. You can use the `cvswrappers' file to record **cvs** wrapper commands to be used when checking files into and out of the repository. Wrappers allow the file or directory to be processed on the way in and out of CVS. The intended uses are many, one possible use would be to re‐ format a C file before the file is checked in, so all of the code in the repository looks the same. You can use the `loginfo' file to define programs to execute after any **commit**, which writes a log entry for changes in the repository. These logging programs might be used to append the log message to a file. Or send the log message through electronic mail to a group of devel‐ opers. Or, perhaps, post the log message to a particular newsgroup. You can use the `taginfo' file to define programs to execute after any **tag**or**rtag** operation. These programs might be used to append a message to a file listing the new tag name and the programmer who created it, or send mail to a group of developers, or, perhaps, post a message to a particular newsgroup. You can use the `rcsinfo' file to define forms for log messages. You can use the `editinfo' file to define a program to execute for editing/validating `**cvs** **commit**' log entries. This is most useful when used with a `rcsinfo' forms specification, as it can verify that the proper fields of the form have been filled in by the user committing the change. You can use the `cvsignore' file to specify the default list of files to ignore during **up**‐‐ **date**. You can use the `history' file to record the **cvs** commands that affect the repository. The creation of this file enables history logging. ## FILES ### modules The `modules' file records your definitions of names for collections of source code. **cvs** will use these definitions if you use **cvs** to check in a file with the right format to `**$CVSROOT/CVSROOT/modules,v**'. 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 specify‐ ing 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 defi‐ nition 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_, `**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 de‐ fines 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 in‐ termediate directory levels are used by default, even if _dir_ was a path involving sev‐ eral directory levels. By explicitly specifying _files_ in the module definition after _dir_, you can select par‐ ticular 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 ex‐ ample: **m4test** **unsupported/gnu/m4** **foreach.m4** **forloop.m4** With this definition, executing `**cvs** **checkout** **m4test**' will create a single working di‐ rectory `m4test' containing the two files listed, which both come from a common direc‐ tory several levels deep in the **cvs** source repository. A module definition can refer to other modules by including `**&**_module_' in its defini‐ tion. **checkout** creates a subdirectory for each such _module_, in your working directo‐ ry. _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_', to name the working directory something other than the module name. _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 direc‐ tory in a source repository. The `commitinfo', `loginfo', and `editinfo' files pro‐ vide 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 execut‐ ed 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 ex‐ pression, 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 consid‐ ered 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 tem‐ plates can include not only a program name, but whatever list of arguments you wish. 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 argu‐ ments list the files that are being modified, added, or removed by this **commit** invoca‐ tion. For `taginfo', the rest of the line is a command-line template to execute. The argu‐ ments passed to the command are, in order, the _tagname_ _,_ _operation_ (i.e. **add** for `tag', **mov** for `tag -F', and **del** for `tag -d`), _repository_ _,_ and any remaining are pairs of **filename** **revision** **.** A non-zero exit of the filter program will cause the tag to be aborted. For `commitinfo', the rest of the line is a command-line template to execute. The template can include not only a program name, but whatever list of arguments you wish. The full path to the current source repository is appended to the template, followed by the file names of any files involved in the commit (added, removed, and modified files). For `rcsinfo', the rest of the line is the full path to a file that should be loaded into the log message template. For `editinfo', the rest of the line is a command-line template to execute. The tem‐ plate can include not only a program name, but whatever list of arguments you wish. The full path to the current log message template file is appended to the template. You can use one of two special strings instead of a regular expression: `**ALL**' speci‐ fies a command line template that must always be executed, and `**DEFAULT**' specifies a command line template to use if no regular expression is a match. The `commitinfo' file contains commands to execute _before_ any other **commit** activity, to allow you to check any conditions that must be satisfied before **commit** can proceed. The rest of the **commit** will execute only if all selected commands from this file exit with exit status **0**. The `rcsinfo' file allows you to specify _log_ _templates_ for the **commit** logging session; you can use this to provide a form to edit when filling out the **commit** log. The field after the regular expression, in this file, contains filenames (of files containing the logging forms) rather than command templates. The `editinfo' file allows you to execute a script _before_ _the_ _commit_ _starts_, but after the log information is recorded. These "edit" scripts can verify information recorded in the log file. If the edit script exits with a non-zero exit status, the commit is aborted. The `loginfo' file contains commands to execute _at_ _the_ _end_ of a commit. The text specified as a commit log message is piped through the command; typical uses include sending mail, filing an article in a newsgroup, or appending to a central file. **cvsignore**, **.cvsignore** The default list of files (or [**sh**(**1**)](https://www.chedong.com/phpMan.php/man/sh/1/markdown) file name patterns) to ignore during `**cvs** **update**'. At startup time, **cvs** loads the compiled in default list of file name patterns (see [**cvs**(**1**)](https://www.chedong.com/phpMan.php/man/cvs/1/markdown)). Then the per-repository list included in **$CVSROOT/CVSROOT/cvsignore** is load‐ ed, if it exists. Then the per-user list is loaded from `$HOME/.cvsignore'. Finally, as **cvs** traverses through your directories, it will load any per-directory `.cvsignore' files whenever it finds one. These per-directory files are only valid for exactly the directory that contains them, not for any sub-directories. ### history Create this file in **$CVSROOT/CVSROOT** to enable history logging (see the description of `**cvs** **history**'). ## SEE ALSO [**cvs**(**1**)](https://www.chedong.com/phpMan.php/man/cvs/1/markdown), ## COPYING Copyright © 1992 Cygnus Support, Brian Berliner, and Jeff Polk Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con‐ ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan‐ guage, under the above conditions for modified versions, except that this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English. 12 February 1992 [cvs(5)](https://www.chedong.com/phpMan.php/man/cvs/5/markdown)