1cvs(5) File Formats Manual cvs(5)
2
6 cvs - Concurrent Versions System support files
7
9 This documentation may no longer be up to date. Please consult the
10 Cederqvist (CVS Manual) as specified in cvs(1).
11
14 $CVSROOT/CVSROOT/commitinfo,v
15 $CVSROOT/CVSROOT/cvsignore,v
17 $CVSROOT/CVSROOT/cvswrappers,v
19 $CVSROOT/CVSROOT/editinfo,v
21 $CVSROOT/CVSROOT/history
23 $CVSROOT/CVSROOT/loginfo,v
25 $CVSROOT/CVSROOT/modules,v
27 $CVSROOT/CVSROOT/rcsinfo,v
29 $CVSROOT/CVSROOT/taginfo,v
31
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 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 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 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 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 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 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 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 You can use the `rcsinfo' file to define forms for log messages.
80 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 You can use the `cvsignore' file to specify the default list of files
88 to ignore during update.
89 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
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 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 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 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 mname [ options ] dir [ files... ] [ &module... ]
121 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 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 m4test unsupported/gnu/m4 foreach.m4 forloop.m4
138 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 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 Finally, you can use one or more of the following options in
151 module definitions:
152 `-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 `-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 `-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 `-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 `-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 `-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 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 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 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 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 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 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 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 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 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 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 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 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 history
264 Create this file in $CVSROOT/CVSROOT to enable history logging
265 (see the description of `cvs history').
266
268 cvs(1),
269
271 Copyright © 1992 Cygnus Support, Brian Berliner, and Jeff Polk
272 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 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 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 12 February 1992 cvs(5)