Penguin
Recent Changes
Annotated edit history of cvs(5) version 1, including all changes. View license author blame.
Rev Author # Line
1 perry 1 cvs
2 !!!cvs
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 FILES
7 SEE ALSO
8 COPYING
9 ----
10 !!NAME
11
12
13 cvs - Concurrent Versions System support files
14 !!SYNOPSIS
15
16
17 __$CVSROOT/CVSROOT/commitinfo,v__
18
19
20 __$CVSROOT/CVSROOT/cvsignore,v__
21
22
23 __$CVSROOT/CVSROOT/cvswrappers,v__
24
25
26 __$CVSROOT/CVSROOT/editinfo,v__
27
28
29 __$CVSROOT/CVSROOT/history__
30
31
32 __$CVSROOT/CVSROOT/loginfo,v__
33
34
35 __$CVSROOT/CVSROOT/modules,v__
36
37
38 __$CVSROOT/CVSROOT/rcsinfo,v__
39
40
41 __$CVSROOT/CVSROOT/taginfo,v__
42 !!DESCRIPTION
43
44
45 __cvs__ is a system for providing source control to
46 hierarchi- cal collections of source directories. Commands
47 and pro- cedures for using __cvs__ are described in
48 __cvs__(__1__).
49
50
51 __cvs__ manages ''source repositories'', the
52 directories contain- ing master copies of the
53 revision-controlled files, by copying particular revisions
54 of the files to (and modifi- cations back from) developers'
55 private ''working directo- ries''. In terms of file
56 structure, each individual source repository is an immediate
57 subdirectory of __$CVSROOT__.
58
59
60 The files described here are supporting files; they do not
61 have to exist for __cvs__ to operate, but they allow you
62 to make __cvs__ operation more flexible.
63
64
65 You can use the `modules' file to define symbolic names for
66 collections of source maintained with __cvs__. If there
67 is no `modules' file, developers must specify complete path
68 names (absolute, or relative to __$CVSROOT__) for the
69 files they wish to manage with __cvs__
70 commands.
71
72
73 You can use the `commitinfo' file to define programs to
74 execute whenever `__cvs commit__' is about to execute.
75 These programs are used for ``pre-commit'' checking to
76 verify that the modified, added, and removed files are
77 really ready to be committed. Some uses for this check might
78 be to turn off a portion (or all) of the source repository
79 from a particular person or group. Or, perhaps, to verify
80 that the changed files conform to the site's standards for
81 coding practice.
82
83
84 You can use the `cvswrappers' file to record __cvs__
85 wrapper commands to be used when checking files into and out
86 of the repository. Wrappers allow the file or directory to
87 be processed on the way in and out of CVS. The intended uses
88 are many, one possible use would be to reformat a C file
89 before the file is checked in, so all of the code in the
90 repository looks the same.
91
92
93 You can use the `loginfo' file to define programs to exe-
94 cute after any __commit__, which writes a log entry for
95 changes in the repository. These logging programs might be
96 used to append the log message to a file. Or send the log
97 message through electronic mail to a group of develop- ers.
98 Or, perhaps, post the log message to a particular
99 newsgroup.
100
101
102 You can use the `taginfo' file to define programs to exe-
103 cute after any __tag__or__rtag__ operation. These
104 programs might be used to append a message to a file listing
105 the new tag name and the programmer who created it, or send
106 mail to a group of developers, or, perhaps, post a message
107 to a par- ticular newsgroup.
108
109
110 You can use the `rcsinfo' file to define forms for log
111 messages.
112
113
114 You can use the `editinfo' file to define a program to ex-
115 ecute for editing/validating `__cvs commit__' log
116 entries. This is most useful when used with a `rcsinfo'
117 forms spec- ification, as it can verify that the proper
118 fields of the form have been filled in by the user
119 committing the change.
120
121
122 You can use the `cvsignore' file to specify the default list
123 of files to ignore during __update__.
124
125
126 You can use the `history' file to record the __cvs__
127 commands that affect the repository. The creation of this
128 file en- ables history logging.
129 !!FILES
130
131
132 __modules__
133
134
135 The `modules' file records your definitions of names for
136 collections of source code. __cvs__ will use these
137 definitions if you use __cvs__ to check in a file with
138 the right format to `__$CVSROOT/CVSROOT/mod-
139 ules,v__'.
140
141
142 The `modules' file may contain blank lines and com- ments
143 (lines beginning with `__#__') as well as module
144 definitions. Long lines can be continued on the next line by
145 specifying a backslash (``'') as the last character on the
146 line.
147
148
149 A ''module definition'' is a single line of the `mod-
150 ules' file, in either of two formats. In both cas- es,
151 ''mname'' represents the symbolic module name, and the
152 remainder of the line is its definition.
153
154
155 ''mname'' __-a__ ''aliases''...
156 This represents the simplest way of defining a mod- ule
157 ''mname''. The `__-a__' flags the definition as a sim-
158 ple alias: __cvs__ will treat any use of ''mname'' (as
159 a command argument) as if the list of names ''aliases''
160 had been specified instead. ''aliases'' may contain
161 either other module names or paths. When you use paths in
162 ''aliases'', `__cvs checkout__' creates all inter-
163 mediate directories in the working directory, just as if the
164 path had been specified explicitly in the __cvs__
165 arguments.
166
167
168 ''mname'' [[ ''options'' ] ''dir'' [[ ''files''... ] [[ ____''module''... ]
169 In the simplest case, this form of module defini- tion reduces to `''mname dir'''. This defines all the files in directory ''dir'' as module ''mname''. ''dir'' is a relative path (from __$CVSROOT__) to a directory 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.
170
171
172 By explicitly specifying ''files'' in the module defi-
173 nition after ''dir'', you can select particular files
174 from directory ''dir''. The sample definition for __mod-
175 ules__ is an example of a module defined with a sin- gle
176 file from a particular directory. Here is an- other
177 example:
178
179
180 __m4test unsupported/gnu/m4 foreach.m4 forloop.m4
181 __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 levels deep in the __cvs__ source repository.
182
183
184 A module definition can refer to other modules by including
185 `____''module''' in its definition.
186 __checkout__ creates a subdirectory for each such
187 ''module'', in your working directory.''
188 New in'' __cvs__ ''1.3;'' avoid this feature if
189 sharing mod- ule definitions with older versions of
190 __cvs__.
191
192
193 Finally, you can use one or more of the following
194 ''options'' in module definitions:
195
196
197 `__-d__ ''name''', to name the working directory
198 something other than the module name.''
199 New in'' __cvs__ ''1.3;'' avoid this feature if
200 sharing mod- ule definitions with older versions of
201 __cvs__.
202
203
204 `__-i__ ''prog''' allows you to specify a program
205 ''prog'' to run whenever files in a module are committed.
206 ''prog'' runs with a single argument, the full pathname
207 of the affected directory in a source repository. The
208 `commitinfo', `loginfo', and `editinfo' files provide other
209 ways to call a program on __commit__.
210
211
212 `__-o__ ''prog''' allows you to specify a program
213 ''prog'' to run whenever files in a module are checked
214 out. ''prog'' runs with a single argument, the module
215 name.
216
217
218 `__-e__ ''prog''' allows you to specify a program
219 ''prog'' to run whenever files in a module are exported.
220 ''prog'' runs with a single argument, the module
221 name.
222
223
224 `__-t__ ''prog''' allows you to specify a program
225 ''prog'' to run whenever files in a module are tagged.
226 ''prog'' runs with two arguments: the module name and the
227 symbolic tag specified to __rtag__.
228
229
230 `__-u__ ''prog''' allows you to specify a program
231 ''prog'' to run whenever `__cvs update__' is executed
232 from the top-level directory of the checked-out module.
233 ''prog'' runs with a single argument, the full path to
234 the source repository for this module.
235
236
237 __commitinfo__, __loginfo__, __rcsinfo__,
238 __editinfo__
239
240
241 These files all specify programs to call at differ- ent
242 points in the `__cvs commit__' process. They have a
243 common structure. Each line is a pair of fields: a regular
244 expression, separated by whitespace from a filename or
245 command-line template. Whenever one of the regular
246 expression matches a directory name in the repository, the
247 rest of the line is used. If the line begins with a __#__
248 character, the entire line is considered a comment and is
249 ignored. Whitespace between the fields is also
250 ignored.
251
252
253 For `loginfo', the rest of the line is a com- mand-line
254 template to execute. The templates can include not only a
255 program name, but whatever list of arguments you wish. If
256 you write `__%s__' somewhere on the argument list,
257 __cvs__ supplies, at that point, the list of files
258 affected by the __commit__. The first entry in the list
259 is the relative path within the source repository where the
260 change is being made. The remaining arguments list the files
261 that are being modified, added, or removed by this __com-
262 mit__ invocation.
263
264
265 For `taginfo', the rest of the line is a com- mand-line
266 template to execute. The arguments passed to the command
267 are, in order, the ''tagname , operation'' (i.e.
268 __add__ for `tag', __mov__ for `tag -F', and
269 __del__ for `tag -d`), ''repository ,'' and any
270 remain- ing are pairs of __filename revision .__ A
271 non-zero exit of the filter program will cause the tag to be
272 aborted.
273
274
275 For `commitinfo', the rest of the line is a com- mand-line
276 template to execute. The template can include not only a
277 program name, but whatever list of arguments you wish. The
278 full path to the cur- rent source repository is appended to
279 the template, followed by the file names of any files
280 involved in the commit (added, removed, and modified
281 files).
282
283
284 For `rcsinfo', the rest of the line is the full path to a
285 file that should be loaded into the log message
286 template.
287
288
289 For `editinfo', the rest of the line is a com- mand-line
290 template to execute. The template can include not only a
291 program name, but whatever list of arguments you wish. The
292 full path to the cur- rent log message template file is
293 appended to the template.
294
295
296 You can use one of two special strings instead of a regular
297 expression: `__ALL__' specifies a command line template
298 that must always be executed, and `__DE- FAULT__'
299 specifies a command line template to use if no regular
300 expression is a match.
301
302
303 The `commitinfo' file contains commands to execute
304 ''before'' any other __commit__ activity, to allow you
305 to check any conditions that must be satisfied before
306 __commit__ can proceed. The rest of the __commit__
307 will execute only if all selected commands from this file
308 exit with exit status __0__.
309
310
311 The `rcsinfo' file allows you to specify ''log tem-
312 plates'' for the __commit__ logging session; you can
313 use this to provide a form to edit when filling out the
314 __commit__ log. The field after the regular expres- sion,
315 in this file, contains filenames (of files containing the
316 logging forms) rather than command templates.
317
318
319 The `editinfo' file allows you to execute a script ''before
320 the commit starts'', but after the log infor- mation is
321 recorded. These
322 ''
323
324
325 The `loginfo' file contains commands to execute ''at the
326 end'' of a commit. The text specified as a com- mit log
327 message is piped through the command; typi- cal uses include
328 sending mail, filing an article in a newsgroup, or appending
329 to a central file.
330
331
332 __cvsignore__, __.cvsignore__
333
334
335 The default list of files (or __sh__(__1__) file name
336 pat- terns) to ignore during `__cvs update__'. At startup
337 time, __cvs__ loads the compiled in default list of file
338 name patterns (see __cvs__(__1__)). Then the
339 per-repository list included in __$CVSROOT/CVS-
340 ROOT/cvsignore__ is loaded, if it exists. Then the
341 per-user list is loaded from `$HOME/.cvsignore'. Finally, as
342 __cvs__ traverses through your directories, it will load
343 any per-directory `.cvsignore' files whenever it finds one.
344 These per-directory files are only valid for exactly the
345 directory that con- tains them, not for any
346 sub-directories.
347
348
349 __history__
350
351
352 Create this file in __$CVSROOT/CVSROOT__ to enable his-
353 tory logging (see the description of `__cvs histo-
354 ry__').
355 !!SEE ALSO
356
357
358 __cvs__(__1__),
359 !!COPYING
360
361
362 Copyright 1992 Cygnus Support, Brian Berliner, and Jeff
363 Polk
364
365
366 Permission is granted to make and distribute verbatim copies
367 of this manual provided the copyright notice and this
368 permission notice are preserved on all copies.
369
370
371 Permission is granted to copy and distribute modified ver-
372 sions of this manual under the conditions for verbatim
373 copying, provided that the entire resulting derived work is
374 distributed under the terms of a permission notice identical
375 to this one.
376
377
378 Permission is granted to copy and distribute translations of
379 this manual into another language, under the above con-
380 ditions for modified versions, except that this permission
381 notice may be included in translations approved by the Free
382 Software Foundation instead of in the original En-
383 glish.
384 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.