NAME<\/a> cvs \u2212 Concurrent Versions System support files<\/p>\n This documentation may no longer be up to date. Please consult the Cederqvist (CVS Manual) as specified in cvs<\/b>(1<\/b>).<\/p>\n $CVSROOT\/CVSROOT\/commitinfo,v cvs<\/b> is a system for providing source control to hierarchical collections of source directories. Commands and procedures for using cvs<\/b> are described in cvs<\/b>(1<\/b>).<\/p>\n cvs<\/b> manages source repositories<\/i>, the directories containing master copies of the revision-controlled files, by copying particular revisions of the files to (and modifications back from) developers\u2019 private working directories<\/i>. In terms of file structure, each individual source repository is an immediate subdirectory of $CVSROOT<\/b>.<\/p>\n The files described here are supporting files; they do not have to exist for cvs<\/b> to operate, but they allow you to make cvs<\/b> operation more flexible.<\/p>\n You can use the \u2018modules\u2019 file to define symbolic names for collections of source maintained with cvs<\/b>. If there is no \u2018modules\u2019 file, developers must specify complete path names (absolute, or relative to $CVSROOT<\/b>) for the files they wish to manage with cvs<\/b> commands.<\/p>\n You can use the \u2018commitinfo\u2019 file to define programs to execute whenever \u2018cvs commit<\/b>\u2019 is about to execute. These programs are used for \u2018\u2018pre-commit\u2019\u2019 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 person or group. Or, perhaps, to verify that the changed files conform to the site\u2019s standards for coding practice.<\/p>\n You can use the \u2018cvswrappers\u2019 file to record cvs<\/b> 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 reformat a C file before the file is checked in, so all of the code in the repository looks the same.<\/p>\n You can use the \u2018loginfo\u2019 file to define programs to execute after any commit<\/b>, 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 developers. Or, perhaps, post the log message to a particular newsgroup.<\/p>\n You can use the \u2018taginfo\u2019 file to define programs to execute after any tag<\/b>orrtag<\/b> 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.<\/p>\n You can use the \u2018rcsinfo\u2019 file to define forms for log messages.<\/p>\n You can use the \u2018editinfo\u2019 file to define a program to execute for editing\/validating \u2018cvs commit<\/b>\u2019 log entries. This is most useful when used with a \u2018rcsinfo\u2019 forms specification, as it can verify that the proper fields of the form have been filled in by the user committing the change.<\/p>\n You can use the \u2018cvsignore\u2019 file to specify the default list of files to ignore during update<\/b>.<\/p>\n You can use the \u2018history\u2019 file to record the cvs<\/b> commands that affect the repository. The creation of this file enables history logging.<\/p>\n modules<\/b><\/p>\n The \u2018modules\u2019 file records your definitions of names for collections of source code. cvs<\/b> will use these definitions if you use cvs<\/b> to check in a file with the right format to \u2018$CVSROOT\/CVSROOT\/modules,v<\/b>\u2019.<\/p>\n The \u2018modules\u2019 file may contain blank lines and comments (lines beginning with \u2018#<\/b>\u2019) as well as module definitions. Long lines can be continued on the next line by specifying a backslash (\u2018\u2018\u2019\u2019) as the last character on the line.<\/p>\n A module definition<\/i> is a single line of the \u2018modules\u2019 file, in either of two formats. In both cases, mname<\/i> represents the symbolic module name, and the remainder of the line is its definition.<\/p>\n mname<\/i> \u2212a<\/b> aliases<\/i>… mname<\/i> [ options<\/i> ] dir<\/i> [ files<\/i>… ] [ &<\/b>module<\/i>… ]<\/p>\n In the simplest case, this form of module definition reduces to \u2018mname dir<\/i>\u2019. This defines all the files in directory dir<\/i> as module mname<\/i>. dir<\/i> is a relative path (from $CVSROOT<\/b>) to a directory of source in one of the source repositories. In this case, on checkout<\/b>, a single directory called mname<\/i> is created as a working directory; no intermediate directory levels are used by default, even if dir<\/i> was a path involving several directory levels.<\/p>\n By explicitly specifying files<\/i> in the module definition after dir<\/i>, you can select particular files from directory dir<\/i>. The sample definition for modules<\/b> is an example of a module defined with a single file from a particular directory. Here is another example:<\/p>\n m4test unsupported\/gnu\/m4 foreach.m4 forloop.m4<\/b><\/p>\n With this definition, executing \u2018cvs checkout m4test<\/b>\u2019 will create a single working directory \u2018m4test\u2019 containing the two files listed, which both come from a common directory several levels deep in the cvs<\/b> source repository.<\/p>\n A module definition can refer to other modules by including \u2018&<\/b>module<\/i>\u2019 in its definition. checkout<\/b> creates a subdirectory for each such module<\/i>, in your working directory. Finally, you can use one or more of the following options<\/i> in module definitions:<\/p>\n \u2018\u2212d<\/b> name<\/i>\u2019, to name the working directory something other than the module name. \u2018\u2212i<\/b> prog<\/i>\u2019 allows you to specify a program prog<\/i> to run whenever files in a module are committed. prog<\/i> runs with a single argument, the full pathname of the affected directory in a source repository. The \u2018commitinfo\u2019, \u2018loginfo\u2019, and \u2018editinfo\u2019 files provide other ways to call a program on commit<\/b>.<\/p>\n \u2018\u2212o<\/b> prog<\/i>\u2019 allows you to specify a program prog<\/i> to run whenever files in a module are checked out. prog<\/i> runs with a single argument, the module name.<\/p>\n \u2018\u2212e<\/b> prog<\/i>\u2019 allows you to specify a program prog<\/i> to run whenever files in a module are exported. prog<\/i> runs with a single argument, the module name.<\/p>\n \u2018\u2212t<\/b> prog<\/i>\u2019 allows you to specify a program prog<\/i> to run whenever files in a module are tagged. prog<\/i> runs with two arguments: the module name and the symbolic tag specified to rtag<\/b>.<\/p>\n \u2018\u2212u<\/b> prog<\/i>\u2019 allows you to specify a program prog<\/i> to run whenever \u2018cvs update<\/b>\u2019 is executed from the top-level directory of the checked-out module. prog<\/i> runs with a single argument, the full path to the source repository for this module.<\/p>\n commitinfo<\/b>, loginfo<\/b>, rcsinfo<\/b>, editinfo<\/b><\/p>\n These files all specify programs to call at different points in the \u2018cvs commit<\/b>\u2019 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 #<\/b> character, the entire line is considered a comment and is ignored. Whitespace between the fields is also ignored.<\/p>\n For \u2018loginfo\u2019, the rest of the line is a command-line template to execute. The templates can include not only a program name, but whatever list of arguments you wish. If you write \u2018%s<\/b>\u2019 somewhere on the argument list, cvs<\/b> supplies, at that point, the list of files affected by the commit<\/b>. 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<\/b> invocation.<\/p>\n For \u2018taginfo\u2019, the rest of the line is a command-line template to execute. The arguments passed to the command are, in order, the tagname , operation<\/i> (i.e. add<\/b> for \u2018tag\u2019, mov<\/b> for \u2018tag -F\u2019, and del<\/b> for \u2018tag -d\u2018), repository ,<\/i> and any remaining are pairs of filename revision .<\/b> A non-zero exit of the filter program will cause the tag to be aborted.<\/p>\n For \u2018commitinfo\u2019, 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).<\/p>\n For \u2018rcsinfo\u2019, the rest of the line is the full path to a file that should be loaded into the log message template.<\/p>\n For \u2018editinfo\u2019, 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 log message template file is appended to the template.<\/p>\n You can use one of two special strings instead of a regular expression: \u2018ALL<\/b>\u2019 specifies a command line template that must always be executed, and \u2018DEFAULT<\/b>\u2019 specifies a command line template to use if no regular expression is a match.<\/p>\n The \u2018commitinfo\u2019 file contains commands to execute before<\/i> any other commit<\/b> activity, to allow you to check any conditions that must be satisfied before commit<\/b> can proceed. The rest of the commit<\/b> will execute only if all selected commands from this file exit with exit status 0<\/b>.<\/p>\n The \u2018rcsinfo\u2019 file allows you to specify log templates<\/i> for the commit<\/b> logging session; you can use this to provide a form to edit when filling out the commit<\/b> log. The field after the regular expression, in this file, contains filenames (of files containing the logging forms) rather than command templates.<\/p>\n The \u2018editinfo\u2019 file allows you to execute a script before the commit starts<\/i>, 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.<\/p>\n The \u2018loginfo\u2019 file contains commands to execute at the end<\/i> 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.<\/p>\n cvsignore<\/b>, .cvsignore<\/b><\/p>\n The default list of files (or sh<\/b>(1<\/b>) file name patterns) to ignore during \u2018cvs update<\/b>\u2019. At startup time, cvs<\/b> loads the compiled in default list of file name patterns (see cvs<\/b>(1<\/b>)). Then the per-repository list included in $CVSROOT\/CVSROOT\/cvsignore<\/b> is loaded, if it exists. Then the per-user list is loaded from \u2018$HOME\/.cvsignore\u2019. Finally, as cvs<\/b> traverses through your directories, it will load any per-directory \u2018.cvsignore\u2019 files whenever it finds one. These per-directory files are only valid for exactly the directory that contains them, not for any sub-directories.<\/p>\n history<\/b><\/p>\n Create this file in $CVSROOT\/CVSROOT<\/b> to enable history logging (see the description of \u2018cvs history<\/b>\u2019).<\/p>\n
NOTE<\/a>
SYNOPSIS<\/a>
DESCRIPTION<\/a>
FILES<\/a>
SEE ALSO<\/a>
COPYING<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
NOTE <\/a> <\/h2>\n
SYNOPSIS <\/a> <\/h2>\n
$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<\/b><\/p>\nDESCRIPTION <\/a> <\/h2>\n
FILES <\/a> <\/h2>\n
This represents the simplest way of defining a module mname<\/i>. The \u2018\u2212a<\/b>\u2019 flags the definition as a simple alias: cvs<\/b> will treat any use of mname<\/i> (as a command argument) as if the list of names aliases<\/i> had been specified instead. aliases<\/i> may contain either other module names or paths. When you use paths in aliases<\/i>, \u2018cvs checkout<\/b>\u2019 creates all intermediate directories in the working directory, just as if the path had been specified explicitly in the cvs<\/b> arguments.<\/p>\n
New in<\/i> cvs<\/b> 1.3;<\/i> avoid this feature if sharing module definitions with older versions of cvs<\/b>.<\/p>\n
New in<\/i> cvs<\/b> 1.3;<\/i> avoid this feature if sharing module definitions with older versions of cvs<\/b>.<\/p>\nSEE ALSO <\/a> <\/h2>\n