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
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 --diffs-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. -A Show ancestor branch when a new
111 branch is found.
112
113 <repository>
114 Operate on the specified repository (overrides working dir.)
115
117 Tags are fundamentally 'file at a time' in cvs, but like everything
118 else, it would be nice to imagine that they are 'repository at a time.'
119 The approach cvsps takes is that a tag is assigned to a patchset. The
120 meaning of this is that after this patchset, every revision of every
121 file is after the tag (and conversely, before this patchset, at least
122 one file is still before the tag). However, there are two kinds of
123 inconsistent (or 'funky') tags that can be created, even when following
124 best practices for cvs.
125
126 The first is what is called a FUNKY tag. A funky tag is one where
127 there are patchsets which are chronologically (and thus by patchset id)
128 earlier than the tag, but are tagwise after. These tags will be marked
129 as '**FUNKY**' in the Tag: section of the cvsps output. When a funky
130 tag is specified as one of the '-r' arguments, there are some number of
131 patchsets which need to be considered out of sequence. In this case,
132 the patchsets themselves will be labeled FUNKY and will be processed
133 correctly.
134
135 The second is called an INVALID tag. An invalid tag is a tag where
136 there are patchsets which are chronologically (and thus by patchset id)
137 earlier than the tag, but which have members which are tagwise both
138 before, and after the tag, in the same patchset. If an INVALID tag is
139 specified as one of the '-r' arguments, cvsps will flag each member of
140 the affected patchsets as before or after the tag and the patchset sum‐
141 mary will indicate which members are which, and diffs will be generated
142 accordingly.
143
145 Among the different cvs subcommands used by cvsps is the 'rlog' com‐
146 mand. The rlog command is used to get revision history of a module,
147 and it disregards the current working directory. The important differ‐
148 ence between 'rlog' and 'log' (from cvsps perspective) is the 'rlog'
149 will include log data for files not in the current working directory.
150 The impact of this is mainly when there are directories which at one
151 time had files, but are now empty, and have been pruned from the work‐
152 ing directory with the '-P' option. If 'rlog' is not used, these files
153 logs will not be parsed, and the PatchSet numbering will be unstable.
154
155 The main problem with 'rlog' is that, until cvs version 1.11.1, 'rlog'
156 was an alias for the 'log' command. This means, for old versions of
157 cvs, 'rlog' has different semantics and usage. cvsps will attempt to
158 work around this problem by detecting capable versions of cvs. If an
159 old version is detected, 'log' will be used instead of 'rlog', and
160 YMMV.
161
163 Another important note is that cvsps will attempt, whenever possible,
164 to use the r-commands (rlog, rdiff and co) instead of the local com‐
165 mands (log, diff, and update). This is to allow cvsps to function
166 without a completely checked out tree. Because these r-commands are
167 used, the generated diffs will include the module directory in them,
168 and it is recommended to apply them in the working directory with the
169 -p1 option to the patch command. However, if the --diff-opts option is
170 specified (to change, for example, the lines of context), then rdiff
171 cannot be used, because it doesn't support arbitrary options. In this
172 case, the patches will be generated without the module directory in the
173 path, and -p0 will be required when applying the patch. When diffs are
174 generated in cvs-direct mode (see below), however, they will always be
175 -p1 style patches.
176
178 The --bkcvs option is a special operating mode that should only be used
179 when parsing the log files from the BK -> CVS exported linux kernel
180 trees. cvsps uses special semantics for recreating the BK ChangeSet
181 metadata that has been embedded in the log files for those trees. The
182 --bkcvs option should only be specified when the cache file is being
183 created or updated (i.e. initial run of cvsps, or when -u and -x
184 options are used).
185
187 As of version 2.0b6 cvsps has a partial implementation of the cvs
188 client code built in. This reduces the RTT and/or handshaking overhead
189 from one per patchset member to one per patchset. This dramatically
190 increases the speed of generating diffs over a slow link, and improves
191 the consistency of operation. Currently the --cvs-direct option turns
192 on the use of this code, but it very well may be default by the time
193 2.0 comes out. The built-in cvs code attempts to be compatible with
194 cvs, but may have problems, which should be reported. It honors the
195 CVS_RSH and CVS_SERVER environment variables, but does not parse the
196 ~/.cvsrc file.
197
199 CVSps parses an rc file at startup. This file should be located in
200 ~/.cvsps/cvspsrc. The file should contain arguments, in the exact syn‐
201 tax as the command line, one per line. If an argument takes a parame‐
202 ter, the parameter should be on the same line as the argument.
203
205 All dates are reported in localtime. This can be overridden (as usual)
206 using the TZ environment variable. Dates as arguments must be in the
207 format 'yyyy/mm/dd hh:mm:ss'; for example,
208
209 $ cvsps -d '2004/05/01 00:00:00' -d '2004/07/07 12:00:00'
210
212 cvs(1), ci(1), co(1), cvs(5), cvsbug(8), diff(1), grep(1), patch(1),
213 rcs(1), rcsdiff(1), rcsmerge(1), rlog(1).
214
216 Report bugs to "David Mansfield <cvsps@dm.cobite.com>"
217
219 No known bugs.
220
221
222
223
224 cvsps(1)