1cvs(5)                        File Formats Manual                       cvs(5)
2
3
4

NAME

6       cvs - Concurrent Versions System support files
7

NOTE

9       This  documentation  may  no  longer be up to date.  Please consult the
10       Cederqvist (CVS Manual) as specified in cvs(1).
11
12

SYNOPSIS

14       $CVSROOT/CVSROOT/commitinfo,v
15
16       $CVSROOT/CVSROOT/cvsignore,v
17
18       $CVSROOT/CVSROOT/cvswrappers,v
19
20       $CVSROOT/CVSROOT/editinfo,v
21
22       $CVSROOT/CVSROOT/history
23
24       $CVSROOT/CVSROOT/loginfo,v
25
26       $CVSROOT/CVSROOT/modules,v
27
28       $CVSROOT/CVSROOT/rcsinfo,v
29
30       $CVSROOT/CVSROOT/taginfo,v
31

DESCRIPTION

33       cvs is a system for providing source control  to  hierarchical  collec‐
34       tions of source directories.  Commands and procedures for using cvs are
35       described in cvs(1).
36
37       cvs manages source  repositories,  the  directories  containing  master
38       copies  of  the  revision-controlled files, by copying particular revi‐
39       sions of the files to (and modifications back from) developers' private
40       working  directories.   In  terms  of  file  structure, each individual
41       source repository is an immediate subdirectory of $CVSROOT.
42
43       The files described here are supporting files; they do not have to  ex‐
44       ist  for  cvs to operate, but they allow you to make cvs operation more
45       flexible.
46
47       You can use the `modules' file to define symbolic names for collections
48       of source maintained with cvs.  If there is no `modules' file, develop‐
49       ers must specify complete path names (absolute, or  relative  to  $CVS‐
50       ROOT) for the files they wish to manage with cvs commands.
51
52       You can use the `commitinfo' file to define programs to execute whenev‐
53       er `cvs commit' is about to  execute.   These  programs  are  used  for
54       ``pre-commit'' checking to verify that the modified, added, and removed
55       files are really ready to be committed.  Some uses for this check might
56       be  to turn off a portion (or all) of the source repository from a par‐
57       ticular person or group.  Or, perhaps, to verify that the changed files
58       conform to the site's standards for coding practice.
59
60       You can use the `cvswrappers' file to record cvs wrapper commands to be
61       used when checking files into and out of the repository.  Wrappers  al‐
62       low the file or directory to be processed on the way in and out of CVS.
63       The intended uses are many, one possible use would be to reformat  a  C
64       file before the file is checked in, so all of the code in the reposito‐
65       ry looks the same.
66
67       You can use the `loginfo' file to define programs to execute after  any
68       commit,  which writes a log entry for changes in the repository.  These
69       logging programs might be used to append the log message to a file.  Or
70       send  the log message through electronic mail to a group of developers.
71       Or, perhaps, post the log message to a particular newsgroup.
72
73       You can use the `taginfo' file to define programs to execute after  any
74       tagorrtag  operation.  These programs might be used to append a message
75       to a file listing the new tag name and the programmer who  created  it,
76       or send mail to a group of developers, or, perhaps, post a message to a
77       particular newsgroup.
78
79       You can use the `rcsinfo' file to define forms for log messages.
80
81       You can use the `editinfo' file to define  a  program  to  execute  for
82       editing/validating  `cvs commit' log entries.  This is most useful when
83       used with a `rcsinfo' forms specification, as it can  verify  that  the
84       proper  fields  of  the form have been filled in by the user committing
85       the change.
86
87       You can use the `cvsignore' file to specify the default list  of  files
88       to ignore during update.
89
90       You  can  use the `history' file to record the cvs commands that affect
91       the repository.  The creation of this file enables history logging.
92

FILES

94       modules
95              The `modules' file records your definitions of names for collec‐
96              tions of source code.  cvs will use these definitions if you use
97              cvs to check in a file with the right format  to  `$CVSROOT/CVS‐
98              ROOT/modules,v'.
99
100              The  `modules'  file may contain blank lines and comments (lines
101              beginning with `#') as well as module definitions.   Long  lines
102              can  be  continued  on  the  next line by specifying a backslash
103              (``\'') as the last character on the line.
104
105              A module definition is a single line of the `modules'  file,  in
106              either of two formats.  In both cases, mname represents the sym‐
107              bolic module name, and the remainder of the line is its  defini‐
108              tion.
109
110              mname -a aliases...
111              This  represents  the  simplest  way of defining a module mname.
112              The `-a' flags the definition as a simple alias: cvs will  treat
113              any use of mname (as a command argument) as if the list of names
114              aliases had been specified instead.  aliases may contain  either
115              other  module  names  or  paths.  When you use paths in aliases,
116              `cvs checkout' creates all intermediate directories in the work‐
117              ing directory, just as if the path had been specified explicitly
118              in the cvs arguments.
119
120              mname [ options ] dir [ files... ] [ &module... ]
121
122              In the simplest case, this form of module definition reduces  to
123              `mname  dir'.   This  defines  all the files in directory dir as
124              module mname.  dir is a relative path (from $CVSROOT) to  a  di‐
125              rectory  of  source  in one of the source repositories.  In this
126              case, on checkout, a single directory called mname is created as
127              a  working  directory; no intermediate directory levels are used
128              by default, even if dir was a path involving  several  directory
129              levels.
130
131              By  explicitly  specifying  files in the module definition after
132              dir, you can select particular files from  directory  dir.   The
133              sample  definition for modules is an example of a module defined
134              with a single file from a particular directory.  Here is another
135              example:
136
137              m4test  unsupported/gnu/m4 foreach.m4 forloop.m4
138
139              With  this definition, executing `cvs checkout m4test' will cre‐
140              ate a single working directory `m4test' containing the two files
141              listed,  which  both come from a common directory several levels
142              deep in the cvs source repository.
143
144              A module definition can refer  to  other  modules  by  including
145              `&module'  in  its  definition.  checkout creates a subdirectory
146              for each such module, in your working directory.
147              New in cvs 1.3; avoid this feature if sharing module definitions
148              with older versions of cvs.
149
150              Finally,  you  can  use  one or more of the following options in
151              module definitions:
152
153              `-d name', to name the working directory  something  other  than
154              the module name.
155              New in cvs 1.3; avoid this feature if sharing module definitions
156              with older versions of cvs.
157
158              `-i prog' allows you to specify a program prog to  run  whenever
159              files  in a module are committed.  prog runs with a single argu‐
160              ment, the full pathname of the affected directory  in  a  source
161              repository.    The `commitinfo', `loginfo', and `editinfo' files
162              provide other ways to call a program on commit.
163
164              `-o prog' allows you to specify a program prog to  run  whenever
165              files  in a module are checked out.  prog runs with a single ar‐
166              gument, the module name.
167
168              `-e prog' allows you to specify a program prog to  run  whenever
169              files  in  a module are exported.  prog runs with a single argu‐
170              ment, the module name.
171
172              `-t prog' allows you to specify a program prog to  run  whenever
173              files  in  a  module  are tagged.  prog runs with two arguments:
174              the module name and the symbolic tag specified to rtag.
175
176              `-u prog' allows you to specify a program prog to  run  whenever
177              `cvs  update'  is  executed  from the top-level directory of the
178              checked-out module.  prog runs with a single argument, the  full
179              path to the source repository for this module.
180
181       commitinfo, loginfo, rcsinfo, editinfo
182              These  files all specify programs to call at different points in
183              the `cvs commit' process.  They have a common  structure.   Each
184              line  is  a  pair  of fields: a regular expression, separated by
185              whitespace from a filename or command-line  template.   Whenever
186              one  of  the  regular expression matches a directory name in the
187              repository, the rest of the line is used.  If  the  line  begins
188              with  a # character, the entire line is considered a comment and
189              is ignored.  Whitespace between the fields is also ignored.
190
191              For `loginfo', the rest of the line is a  command-line  template
192              to  execute.  The templates can include not only a program name,
193              but whatever list of arguments you  wish.   If  you  write  `%s'
194              somewhere on the argument list, cvs supplies, at that point, the
195              list of files affected by the commit.  The first  entry  in  the
196              list is the relative path within the source repository where the
197              change is being made.  The remaining arguments  list  the  files
198              that  are being modified, added, or removed by this commit invo‐
199              cation.
200
201              For `taginfo', the rest of the line is a  command-line  template
202              to  execute.  The arguments passed to the command are, in order,
203              the tagname , operation (i.e.  add for `tag', mov for `tag  -F',
204              and  del for `tag -d`), repository , and any remaining are pairs
205              of filename revision .  A non-zero exit of  the  filter  program
206              will cause the tag to be aborted.
207
208              For  `commitinfo',  the  rest of the line is a command-line tem‐
209              plate to execute.  The template can include not only  a  program
210              name, but whatever list of arguments you wish.  The full path to
211              the current source repository is appended to the template,  fol‐
212              lowed  by  the  file  names  of any files involved in the commit
213              (added, removed, and modified files).
214
215              For `rcsinfo', the rest of the line is the full path to  a  file
216              that should be loaded into the log message template.
217
218              For  `editinfo', the rest of the line is a command-line template
219              to execute.  The template can include not only a  program  name,
220              but  whatever  list of arguments you wish.  The full path to the
221              current log message template file is appended to the template.
222
223              You can use one of two special strings instead of a regular  ex‐
224              pression:  `ALL' specifies a command line template that must al‐
225              ways be executed, and `DEFAULT' specifies a  command  line  tem‐
226              plate to use if no regular expression is a match.
227
228              The  `commitinfo'  file  contains commands to execute before any
229              other commit activity, to allow you to check any conditions that
230              must  be  satisfied  before commit can proceed.  The rest of the
231              commit will execute only if all selected commands from this file
232              exit with exit status 0.
233
234              The  `rcsinfo'  file allows you to specify log templates for the
235              commit logging session; you can use this to provide  a  form  to
236              edit when filling out the commit log.  The field after the regu‐
237              lar expression, in this file, contains filenames (of files  con‐
238              taining the logging forms) rather than command templates.
239
240              The  `editinfo'  file  allows you to execute a script before the
241              commit starts, but after the log information is recorded.  These
242              "edit"  scripts can verify information recorded in the log file.
243              If the edit script exits with a non-zero exit status, the commit
244              is aborted.
245
246              The  `loginfo' file contains commands to execute at the end of a
247              commit.  The text specified as a commit  log  message  is  piped
248              through  the  command; typical uses include sending mail, filing
249              an article in a newsgroup, or appending to a central file.
250
251       cvsignore, .cvsignore
252              The default list of files (or sh(1) file name patterns)  to  ig‐
253              nore  during  `cvs update'.  At startup time, cvs loads the com‐
254              piled in default list of file name patterns (see cvs(1)).   Then
255              the  per-repository  list included in $CVSROOT/CVSROOT/cvsignore
256              is loaded, if it exists.  Then the per-user list is loaded  from
257              `$HOME/.cvsignore'.   Finally, as cvs traverses through your di‐
258              rectories, it will load  any  per-directory  `.cvsignore'  files
259              whenever it finds one.  These per-directory files are only valid
260              for exactly the directory that contains them, not for  any  sub-
261              directories.
262
263       history
264              Create  this  file in $CVSROOT/CVSROOT to enable history logging
265              (see the description of `cvs history').
266

SEE ALSO

268       cvs(1),
269

COPYING

271       Copyright © 1992 Cygnus Support, Brian Berliner, and Jeff Polk
272
273       Permission is granted to make and distribute verbatim  copies  of  this
274       manual  provided  the  copyright  notice and this permission notice are
275       preserved on all copies.
276
277       Permission is granted to copy and distribute modified versions of  this
278       manual under the conditions for verbatim copying, provided that the en‐
279       tire resulting derived work is distributed under the terms of a permis‐
280       sion notice identical to this one.
281
282       Permission is granted to copy and distribute translations of this manu‐
283       al into another language, under the above conditions for modified  ver‐
284       sions,  except  that this permission notice may be included in transla‐
285       tions approved by the Free Software Foundation instead of in the origi‐
286       nal English.
287
288
289
290                               12 February 1992                         cvs(5)
Impressum