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 speci-fied specified
fied 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 collections of source directories. Com-mands Commands
mands 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' pri-vate private
vate working directories. In terms of file structure, each individual source repository is an imme-diate immediate
diate 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 rela-tive relative
tive 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 ex-ecute. execute.
ecute. 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 por-tion portion
tion (or all) of the source repository from a particular 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 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.
You can use the `loginfo' file to define programs to execute after any commit, which writes a log en-try entry
try 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 news-group. newsgroup.
group.
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 collections of source code. cvs will
use these definitions if you use cvs to check in a file with the right format to `$CVS-ROOT/CVSROOT/modules,v'. `$CVSROOT/CVSROOT/modules,v'.
ROOT/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 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 defini-tion. definition.
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 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 di-rectory directory
rectory of source in one of the source repositories. In this case, on checkout, a single di-rectory directory
rectory 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 lev-els levels
els 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 commit-ted. committed.
ted. 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 expres-sion expression
sion 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 invocation.
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 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 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 expression: `ALL' specifies a com-mand command
mand line template that must always be executed, and `DEFAULT' specifies a command line tem-plate template
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 regular
lar 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) 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)). 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
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),
COPYING
Copyright (C) 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 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 language, 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)
|