1cvsps(1) General Commands Manual cvsps(1)
2
3
4
6 CVSps - create patchset information from CVS
7
9 cvsps [-h] [-x] [-u] [-z <fuzz>] [-g] [-s <patchset>] [-a <author>] [-f
10 <file>] [-d <date1> [-d <date2>]] [-l <text>] [-b <branch>] [-r <tag>
11 [-r <tag>]] [-p <directory>] [-v] [-t] [--norc] [--summary-first]
12 [--test-log <filename>] [--bkcvs] [--no-rlog] [--diff-opts <option
13 string>] [--cvs-direct] [--debuglvl <bitmask>] [-Z <compression>]
14 [--root <cvsroot>] [-q] [-A] [<repository>]
15
17 CVSps is a program for generating 'patchset' information from a CVS
18 repository. A patchset in this case is defined as a set of changes
19 made to a collection of files, and all committed at the same time
20 (using a single 'cvs commit' command). This information is valuable to
21 seeing the big picture of the evolution of a cvs project. While cvs
22 tracks revision information, it is often difficult to see what changes
23 were committed ´atomically' to the repository.
24
26 -h display usage summary
27
28 -x ignore (and rebuild) ~/.cvsps/cvsps.cache file
29
30 -u update ~/.cvsps/cvsps.cache file
31
32 -z <fuzz>
33 set the timestamp fuzz factor for identifying patch sets
34
35 -g generate diffs of the selected patch sets
36
37 -s <patchset>[-[<patchset>]][,<patchset>...]
38 generate a diff for a given patchsets and patchset ranges
39
40 -a <author>
41 restrict output to patchsets created by author
42
43 -f <file>
44 restrict output to patchsets involving file
45
46 -d <date1> -d <date2>
47 if just one date specified, show revisions newer than date1. If
48 two dates specified, show revisions between two dates.
49
50 -l <regex>
51 restrict output to patchsets matching regex in log message
52
53 -b <branch>
54 restrict output to patchsets affecting history of branch. If
55 you want to restrict to the main branch, use a branch of 'HEAD'.
56
57 -r <tag1> -r <tag2>
58 if just one tag specified, show revisions since tag1. If two
59 tags specified, show revisions between the two tags.
60
61 -p <dir>
62 output individual patchsets as files in <dir> as <dir>/<patch‐
63 set>.patch
64
65 -v show very verbose parsing messages
66
67 -t show some brief memory usage statistics
68
69 --norc when invoking cvs, ignore the .cvsrc file
70
71 --summary-first
72 when multiple patchset diffs are being generated, put the patch‐
73 set summary for all patchsets at the beginning of the output.
74
75 --test-log <captured cvs log file>
76 for testing changes, you can capture cvs log output, then test
77 against this captured file instead of hammering some poor CVS
78 server
79
80 --bkcvs
81 (see note below) for use in parsing the BK->CVS tree log formats
82 only. This enables some hacks which are not generally applica‐
83 ble.
84
85 --no-rlog
86 disable the use of rlog internally. Note: rlog is required for
87 stable PatchSet numbering. Use with care.
88
89 --diff-opts <option string>
90 send a custom set of options to diff, for example to increase
91 the number of context lines, or change the diff format.
92
93 --cvs-direct (--no-cvs-direct)
94 enable (disable) built-in cvs client code. This enables the
95 'pipelining' of multiple requests over a single client, reducing
96 the overhead of handshaking and authentication to one per Patch‐
97 Set instead of one per file.
98
99 --debuglvl <bitmask>
100 enable various debug output channels.
101
102 -Z <compression>
103 A value 1-9 which specifies amount of compression. A value of 0
104 disables compression.
105
106 --root <cvsroot>
107 Override the setting of CVSROOT (overrides working dir. and
108 environment). For --cvs-direct only.
109
110 -q Be quiet about warnings.
111
112 -A Show ancestor branch when a new branch is found.
113
114 <repository>
115 Operate on the specified repository (overrides working dir.)
116
118 Tags are fundamentally 'file at a time' in cvs, but like everything
119 else, it would be nice to imagine that they are 'repository at a time.'
120 The approach cvsps takes is that a tag is assigned to a patchset. The
121 meaning of this is that after this patchset, every revision of every
122 file is after the tag (and conversely, before this patchset, at least
123 one file is still before the tag). However, there are two kinds of
124 inconsistent (or 'funky') tags that can be created, even when following
125 best practices for cvs.
126
127 The first is what is called a FUNKY tag. A funky tag is one where
128 there are patchsets which are chronologically (and thus by patchset id)
129 earlier than the tag, but are tagwise after. These tags will be marked
130 as '**FUNKY**' in the Tag: section of the cvsps output. When a funky
131 tag is specified as one of the '-r' arguments, there are some number of
132 patchsets which need to be considered out of sequence. In this case,
133 the patchsets themselves will be labeled FUNKY and will be processed
134 correctly.
135
136 The second is called an INVALID tag. An invalid tag is a tag where
137 there are patchsets which are chronologically (and thus by patchset id)
138 earlier than the tag, but which have members which are tagwise both
139 before, and after the tag, in the same patchset. If an INVALID tag is
140 specified as one of the '-r' arguments, cvsps will flag each member of
141 the affected patchsets as before or after the tag and the patchset sum‐
142 mary will indicate which members are which, and diffs will be generated
143 accordingly.
144
146 Among the different cvs subcommands used by cvsps is the 'rlog' com‐
147 mand. The rlog command is used to get revision history of a module,
148 and it disregards the current working directory. The important differ‐
149 ence between 'rlog' and 'log' (from cvsps perspective) is the 'rlog'
150 will include log data for files not in the current working directory.
151 The impact of this is mainly when there are directories which at one
152 time had files, but are now empty, and have been pruned from the work‐
153 ing directory with the '-P' option. If 'rlog' is not used, these files
154 logs will not be parsed, and the PatchSet numbering will be unstable.
155
156 The main problem with 'rlog' is that, until cvs version 1.11.1, 'rlog'
157 was an alias for the 'log' command. This means, for old versions of
158 cvs, 'rlog' has different semantics and usage. cvsps will attempt to
159 work around this problem by detecting capable versions of cvs. If an
160 old version is detected, 'log' will be used instead of 'rlog', and
161 YMMV.
162
164 Another important note is that cvsps will attempt, whenever possible,
165 to use the r-commands (rlog, rdiff and co) instead of the local com‐
166 mands (log, diff, and update). This is to allow cvsps to function
167 without a completely checked out tree. Because these r-commands are
168 used, the generated diffs will include the module directory in them,
169 and it is recommended to apply them in the working directory with the
170 -p1 option to the patch command. However, if the --diff-opts option is
171 specified (to change, for example, the lines of context), then rdiff
172 cannot be used, because it doesn't support arbitrary options. In this
173 case, the patches will be generated without the module directory in the
174 path, and -p0 will be required when applying the patch. When diffs are
175 generated in cvs-direct mode (see below), however, they will always be
176 -p1 style patches.
177
179 The --bkcvs option is a special operating mode that should only be used
180 when parsing the log files from the BK -> CVS exported linux kernel
181 trees. cvsps uses special semantics for recreating the BK ChangeSet
182 metadata that has been embedded in the log files for those trees. The
183 --bkcvs option should only be specified when the cache file is being
184 created or updated (i.e. initial run of cvsps, or when -u and -x
185 options are used).
186
188 As of version 2.0b6 cvsps has a partial implementation of the cvs
189 client code built in. This reduces the RTT and/or handshaking overhead
190 from one per patchset member to one per patchset. This dramatically
191 increases the speed of generating diffs over a slow link, and improves
192 the consistency of operation. Currently the --cvs-direct option turns
193 on the use of this code, but it very well may be default by the time
194 2.0 comes out. The built-in cvs code attempts to be compatible with
195 cvs, but may have problems, which should be reported. It honors the
196 CVS_RSH and CVS_SERVER environment variables, but does not parse the
197 ~/.cvsrc file.
198
200 CVSps parses an rc file at startup. This file should be located in
201 ~/.cvsps/cvspsrc. The file should contain arguments, in the exact syn‐
202 tax as the command line, one per line. If an argument takes a parame‐
203 ter, the parameter should be on the same line as the argument.
204
206 All dates are reported in localtime. This can be overridden (as usual)
207 using the TZ environment variable. Dates as arguments must be in the
208 format 'yyyy/mm/dd hh:mm:ss'; for example,
209
210 $ cvsps -d '2004/05/01 00:00:00' -d '2004/07/07 12:00:00'
211
213 cvs(1), ci(1), co(1), cvs(5), cvsbug(8), diff(1), grep(1), patch(1),
214 rcs(1), rcsdiff(1), rcsmerge(1), rlog(1).
215
217 Report bugs to "David Mansfield <cvsps@dm.cobite.com>"
218
220 No known bugs.
221
222
223
224
225 cvsps(1)