cvs(5) FILE FORMATS cvs(5)
NAME
cvs - Concurrent Versions System support files
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 directories. Commands and procedures
for using cvs are described in cvs(1).
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 im
mediate 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
(absolute, or relative to $CVSROOT) for the files they wish
to manage with cvs commands.
You can use the `commitinfo' file to define programs to exe
cute whenever `cvs commit' is about to execute. These pro
grams 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 particu
lar person 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 pro
cessed 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.
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 ap
pend the log message to a file. Or send the log message
through electronic mail to a group of developers. Or, per
haps, post the log message to a particular newsgroup.
You can use the `taginfo' file to define programs to execute
after any tagorrtag 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 mes
sages.
You can use the `editinfo' file to define a program to exe
cute for editing/validating `cvs commit' log entries. This
is most useful when used with a `rcsinfo' forms specifica
tion, 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 update.
You can use the `history' file to record the cvs commands
that affect the repository. The creation of this file en
ables 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 defini
tions. 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,
`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 sin
gle directory called mname is created as a working di
rectory; no intermediate directory levels are used by
default, even if dir was a path involving several di
rectory levels.
By explicitly specifying files in the module definition
after dir, you can select particular files from direc
tory dir. The sample definition for modules is an ex
ample 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' con
taining 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 in
cluding `&module' in its definition. checkout 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 op
tions in module definitions:
`-d name', to name the working directory something oth
er 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 af
fected 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 ex
pression 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 on
ly 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 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 com
mand 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 tem
plate.
For `editinfo', 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 tem
plate file is appended to the template.
You can use one of two special strings instead of a
regular expression: `ALL' specifies a command line tem
plate that must always be executed, and `DEFAULT' spec
ifies a command line template to use if no regular ex
pression is a match.
The `commitinfo' file contains commands to execute be
fore 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 be
fore the commit starts, but after the log information
is recorded. These "edit" scripts can verify informa
tion recorded in the log file. If the edit script ex
its wth 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 in
clude sending mail, filing an article in a newsgroup,
or appending to a central file.
cvsignore, .cvsignore
The default list of files (or sh(1) file name patterns)
to ignore during `cvs update'. At startup time, cvs
loads the compiled in default list of file name pat
terns (see cvs(1)). Then the per-repository list in
cluded in $CVSROOT/CVSROOT/cvsignore is loaded, 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 directo
ry 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),
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 per
mission notice are preserved on all copies.
Permission is granted to copy and distribute modified ver
sions of this manual under the conditions for verbatim copy
ing, provided that the entire resulting derived work is dis
tributed under the terms of a permission notice identical to
this one.
Permission is granted to copy and distribute translations of
this manual into another language, under the above condi
tions for modified versions, except that this permission no
tice may be included in translations approved by the Free
Software Foundation instead of in the original English.
Sun Release 4.1 Last change: 12 February 1992 1