cvs(5) File Formats Manual cvs(5) #
cvs(5) File Formats Manual cvs(5)
NNAAMMEE #
cvs - Concurrent Versions System support files
SSYYNNOOPPSSIISS #
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//ccoommmmiittiinnffoo,,vv
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//ccvvssiiggnnoorree,,vv
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//ccvvsswwrraappppeerrss,,vv
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//eeddiittiinnffoo,,vv
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//hhiissttoorryy
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//llooggiinnffoo,,vv
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//mmoodduulleess,,vv
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//rrccssiinnffoo,,vv
$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//ttaaggiinnffoo,,vv
DDEESSCCRRIIPPTTIIOONN #
ccvvss is a system for providing source control to hierarchical collections
of source directories. Commands and procedures for using ccvvss are
described in ccvvss(11).
ccvvss manages _s_o_u_r_c_e _r_e_p_o_s_i_t_o_r_i_e_s, the directories containing master copies
of the revision-controlled files, by copying particular revisions of the
files to (and modifications back from) developers' private _w_o_r_k_i_n_g
_d_i_r_e_c_t_o_r_i_e_s. In terms of file structure, each individual source
repository is an immediate subdirectory of $$CCVVSSRROOOOTT.
The files described here are supporting files; they do not have to exist
for ccvvss to operate, but they allow you to make ccvvss operation more
flexible.
You can use the `modules' file to define symbolic names for collections
of source maintained with ccvvss. If there is no `modules' file, developers
must specify complete path names (absolute, or relative to $$CCVVSSRROOOOTT) for
the files they wish to manage with ccvvss commands.
You can use the `commitinfo' file to define programs to execute whenever
`ccvvss ccoommmmiitt' 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
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 ccvvss 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
ccoommmmiitt, 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
ttaagg or rrttaagg 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 `ccvvss ccoommmmiitt' 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 uuppddaattee.
You can use the `history' file to record the ccvvss commands that affect the
repository. The creation of this file enables history logging.
FFIILLEESS #
mmoodduulleess
The `modules' file records your definitions of names for
collections of source code. ccvvss will use these definitions if you
use ccvvss to check in a file with the right format to
`$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//mmoodduulleess,,vv'.
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 _m_o_d_u_l_e _d_e_f_i_n_i_t_i_o_n is a single line of the `modules' file, in
either of two formats. In both cases, _m_n_a_m_e represents the
symbolic module name, and the remainder of the line is its
definition.
_m_n_a_m_e --aa _a_l_i_a_s_e_s...
This represents the simplest way of defining a module _m_n_a_m_e. The
`--aa' flags the definition as a simple alias: ccvvss will treat any
use of _m_n_a_m_e (as a command argument) as if the list of names
_a_l_i_a_s_e_s had been specified instead. _a_l_i_a_s_e_s may contain either
other module names or paths. When you use paths in _a_l_i_a_s_e_s, `ccvvss
cchheecckkoouutt' creates all intermediate directories in the working
directory, just as if the path had been specified explicitly in
the ccvvss arguments.
_m_n_a_m_e [ _o_p_t_i_o_n_s ] _d_i_r [ _f_i_l_e_s... ] [ &&_m_o_d_u_l_e... ]
In the simplest case, this form of module definition reduces to
`_m_n_a_m_e _d_i_r'. This defines all the files in directory _d_i_r as
module _m_n_a_m_e. _d_i_r is a relative path (from $$CCVVSSRROOOOTT) to a
directory of source in one of the source repositories. In this
case, on cchheecckkoouutt, a single directory called _m_n_a_m_e is created as a
working directory; no intermediate directory levels are used by
default, even if _d_i_r was a path involving several directory
levels.
By explicitly specifying _f_i_l_e_s in the module definition after _d_i_r,
you can select particular files from directory _d_i_r. The sample
definition for mmoodduulleess is an example of a module defined with a
single file from a particular directory. Here is another example:
mm44tteesstt uunnssuuppppoorrtteedd//ggnnuu//mm44 ffoorreeaacchh..mm44 ffoorrlloooopp..mm44
With this definition, executing `ccvvss cchheecckkoouutt mm44tteesstt' will create
a single working directory `m4test' containing the two files
listed, which both come from a common directory several levels
deep in the ccvvss source repository.
A module definition can refer to other modules by including
`&&_m_o_d_u_l_e' in its definition. cchheecckkoouutt creates a subdirectory for
each such _m_o_d_u_l_e, in your working directory.
_N_e_w _i_n ccvvss _1_._3_; avoid this feature if sharing module definitions
with older versions of ccvvss.
Finally, you can use one or more of the following _o_p_t_i_o_n_s in
module definitions:
`--dd _n_a_m_e', to name the working directory something other than the
module name.
_N_e_w _i_n ccvvss _1_._3_; avoid this feature if sharing module definitions
with older versions of ccvvss.
`--ii _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever
files in a module are committed. _p_r_o_g 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 ccoommmmiitt.
`--oo _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever
files in a module are checked out. _p_r_o_g runs with a single
argument, the module name.
`--ee _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever
files in a module are exported. _p_r_o_g runs with a single argument,
the module name.
`--tt _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever
files in a module are tagged. _p_r_o_g runs with two arguments: the
module name and the symbolic tag specified to rrttaagg.
`--uu _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever
`ccvvss uuppddaattee' is executed from the top-level directory of the
checked-out module. _p_r_o_g runs with a single argument, the full
path to the source repository for this module.
ccoommmmiittiinnffoo, llooggiinnffoo, rrccssiinnffoo, eeddiittiinnffoo
These files all specify programs to call at different points in
the `ccvvss ccoommmmiitt' 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 `%%ss' somewhere
on the argument list, ccvvss supplies, at that point, the list of
files affected by the ccoommmmiitt. 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 ccoommmmiitt 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
_t_a_g_n_a_m_e _, _o_p_e_r_a_t_i_o_n (i.e. aadddd for `tag', mmoovv for `tag -F', and
ddeell for `tag -d`), _r_e_p_o_s_i_t_o_r_y _, and any remaining are pairs of
ffiilleennaammee rreevviissiioonn .. 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: `AALLLL' specifies a command line template that must
always be executed, and `DDEEFFAAUULLTT' specifies a command line
template to use if no regular expression is a match.
The `commitinfo' file contains commands to execute _b_e_f_o_r_e any
other ccoommmmiitt activity, to allow you to check any conditions that
must be satisfied before ccoommmmiitt can proceed. The rest of the
ccoommmmiitt will execute only if all selected commands from this file
exit with exit status 00.
The `rcsinfo' file allows you to specify _l_o_g _t_e_m_p_l_a_t_e_s for the
ccoommmmiitt logging session; you can use this to provide a form to edit
when filling out the ccoommmmiitt 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 _b_e_f_o_r_e _t_h_e
_c_o_m_m_i_t _s_t_a_r_t_s, but after the log information is recorded. These
"edit" scripts can verify information recorded in the log file.
If the edit script exits wth a non-zero exit status, the commit is
aborted.
The `loginfo' file contains commands to execute _a_t _t_h_e _e_n_d 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.
ccvvssiiggnnoorree, ..ccvvssiiggnnoorree
The default list of files (or sshh(11) file name patterns) to ignore
during `ccvvss uuppddaattee'. At startup time, ccvvss loads the compiled in
default list of file name patterns (see ccvvss(11)). Then the per-
repository list included in $$CCVVSSRROOOOTT//CCVVSSRROOOOTT//ccvvssiiggnnoorree is loaded,
if it exists. Then the per-user list is loaded from
`$HOME/.cvsignore'. Finally, as ccvvss 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.
hhiissttoorryy
Create this file in $$CCVVSSRROOOOTT//CCVVSSRROOOOTT to enable history logging
(see the description of `ccvvss hhiissttoorryy').
SSEEEE AALLSSOO #
ccvvss(11),
CCOOPPYYIINNGG #
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
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)