cvs(5) cvs(5)
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).
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 collec
tions 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 revi
sions 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 ex
ist 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, develop
ers must specify complete path names (absolute, or relative to $CVS
ROOT) for the files they wish to manage with cvs commands.
You can use the commitinfo file to define programs to execute whenev
er 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 par
ticular person or group. Or, perhaps, to verify that the changed files
conform to the sites 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 al
low 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 reposito
ry 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 developers.
Or, perhaps, 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 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 update.
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 collec
tions of source code. cvs will use these definitions if you use
cvs to check in a file with the right format to $CVSROOT/CVS
ROOT/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 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 sym
bolic module name, and the remainder of the line is its defini
tion.
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 work
ing 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 di
rectory 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 cre
ate 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.
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 argu
ment, 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 ar
gument, 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 argu
ment, 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 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 invo
cation.
For taginfo, 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.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 tem
plate 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, fol
lowed 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 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.
You can use one of two special strings instead of a regular ex
pression: ALL specifies a command line template that must al
ways be executed, and DEFAULT specifies a command line tem
plate 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 regu
lar expression, in this file, contains filenames (of files con
taining 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) file name patterns) to ig
nore during cvs update. At startup time, cvs loads the com
piled in default list of file name patterns (see cvs(1)). Then
the per-repository list included 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 di
rectories, 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),
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 conditions for verbatim copying, provided that the en
tire resulting derived work is distributed under the terms of a permis
sion notice identical to this one.
Permission is granted to copy and distribute translations of this manu
al into another language, under the above conditions for modified ver
sions, except that this permission notice may be included in transla
tions approved by the Free Software Foundation instead of in the origi
nal English.
12 February 1992 cvs(5)
|
