cvsps(1)cvsps(1)NAME
CVSps - create patchset information from CVS
SYNOPSIScvsps [-h] [-x] [-u] [-z <fuzz>] [-g] [-s <patchset>] [-a <author>] [-f
<file>] [-d <date1> [-d <date2>]] [-l <text>] [-b <branch>] [-r <tag>
[-r <tag>]] [-p <directory>] [-v] [-t] [--norc] [--summary-first]
[--test-log <filename>] [--bkcvs] [--no-rlog] [--diff-opts <option
string>] [--cvs-direct] [--debuglvl <bitmask>] [-Z <compression>]
[--root <cvsroot>] [-q] [-A] [<repository>]
DESCRIPTION
CVSps is a program for generating 'patchset' information from a CVS
repository. A patchset in this case is defined as a set of changes
made to a collection of files, and all committed at the same time
(using a single 'cvs commit' command). This information is valuable to
seeing the big picture of the evolution of a cvs project. While cvs
tracks revision information, it is often difficult to see what changes
were committed
OPTIONS-h display usage summary
-x ignore (and rebuild) ~/.cvsps/cvsps.cache file
-u update ~/.cvsps/cvsps.cache file
-z <fuzz>
set the timestamp fuzz factor for identifying patch sets
-g generate diffs of the selected patch sets
-s <patchset>[-[<patchset>]][,<patchset>...]
generate a diff for a given patchsets and patchset ranges
-a <author>
restrict output to patchsets created by author
-f <file>
restrict output to patchsets involving file
-d <date1> -d <date2>
if just one date specified, show revisions newer than date1. If
two dates specified, show revisions between two dates.
-l <regex>
restrict output to patchsets matching regex in log message
-b <branch>
restrict output to patchsets affecting history of branch. If
you want to restrict to the main branch, use a branch of 'HEAD'.
-r <tag1> -r <tag2>
if just one tag specified, show revisions since tag1. If two
1
cvsps(1)cvsps(1)
tags specified, show revisions between the two tags.
-p <dir>
output individual patchsets as files in <dir> as <dir>/<patch-
set>.patch
-v show very verbose parsing messages
-t show some brief memory usage statistics
--norc when invoking cvs, ignore the .cvsrc file
--summary-first
when multiple patchset diffs are being generated, put the patch-
set summary for all patchsets at the beginning of the output.
--test-log <captured cvs log file>
for testing changes, you can capture cvs log output, then test
against this captured file instead of hammering some poor CVS
server
--bkcvs
(see note below) for use in parsing the BK->CVS tree log formats
only. This enables some hacks which are not generally applica-
ble.
--no-rlog
disable the use of rlog internally. Note: rlog is required for
stable PatchSet numbering. Use with care.
--diffs-opts <option string>
send a custom set of options to diff, for example to increase
the number of context lines, or change the diff format.
--cvs-direct (--no-cvs-direct)
enable (disable) built-in cvs client code. This enables the
'pipelining' of multiple requests over a single client, reducing
the overhead of handshaking and authentication to one per Patch-
Set instead of one per file.
--debuglvl <bitmask>
enable various debug output channels.
-Z <compression>
A value 1-9 which specifies amount of compression. A value of 0
disables compression.
--root <cvsroot>
Override the setting of CVSROOT (overrides working dir. and
environment). For --cvs-direct only.
-q Be quiet about warnings. -A Show ancestor branch when a new
branch is found.
2
cvsps(1)cvsps(1)
<repository>
Operate on the specified repository (overrides working dir.)
NOTE ON TAG HANDLING
Tags are fundamentally 'file at a time' in cvs, but like everything
else, it would be nice to imagine that they are 'repository at a time.'
The approach cvsps takes is that a tag is assigned to a patchset. The
meaning of this is that after this patchset, every revision of every
file is after the tag (and conversely, before this patchset, at least
one file is still before the tag). However, there are two kinds of
inconsistent (or 'funky') tags that can be created, even when following
best practices for cvs.
The first is what is called a FUNKY tag. A funky tag is one where
there are patchsets which are chronologically (and thus by patchset id)
earlier than the tag, but are tagwise after. These tags will be marked
as '**FUNKY**' in the Tag: section of the cvsps output. When a funky
tag is specified as one of the '-r' arguments, there are some number of
patchsets which need to be considered out of sequence. In this case,
the patchsets themselves will be labeled FUNKY and will be processed
correctly.
The second is called an INVALID tag. An invalid tag is a tag where
there are patchsets which are chronologically (and thus by patchset id)
earlier than the tag, but which have members which are tagwise both
before, and after the tag, in the same patchset. If an INVALID tag is
specified as one of the '-r' arguments, cvsps will flag each member of
the affected patchsets as before or after the tag and the patchset sum-
mary will indicate which members are which, and diffs will be generated
accordingly.
NOTE ON CVS VERSIONS
Among the different cvs subcommands used by cvsps is the 'rlog' com-
mand. The rlog command is used to get revision history of a module,
and it disregards the current working directory. The important differ-
ence between 'rlog' and 'log' (from cvsps perspective) is the 'rlog'
will include log data for files not in the current working directory.
The impact of this is mainly when there are directories which at one
time had files, but are now empty, and have been pruned from the work-
ing directory with the '-P' option. If 'rlog' is not used, these files
logs will not be parsed, and the PatchSet numbering will be unstable.
The main problem with 'rlog' is that, until cvs version 1.11.1, 'rlog'
was an alias for the 'log' command. This means, for old versions of
cvs, 'rlog' has different semantics and usage. cvsps will attempt to
work around this problem by detecting capable versions of cvs. If an
old version is detected, 'log' will be used instead of 'rlog', and
YMMV.
NOTE ON GENERATED DIFFS
Another important note is that cvsps will attempt, whenever possible,
to use the r-commands (rlog, rdiff and co) instead of the local com-
mands (log, diff, and update). This is to allow cvsps to function
without a completely checked out tree. Because these r-commands are
3
cvsps(1)cvsps(1)
used, the generated diffs will include the module directory in them,
and it is recommended to apply them in the working directory with the
-p1 option to the patch command. However, if the --diff-opts option is
specified (to change, for example, the lines of context), then rdiff
cannot be used, because it doesn't support arbitrary options. In this
case, the patches will be generated without the module directory in the
path, and -p0 will be required when applying the patch. When diffs are
generated in cvs-direct mode (see below), however, they will always be
-p1 style patches.
NOTE ON BKCVS
The --bkcvs option is a special operating mode that should only be used
when parsing the log files from the BK -> CVS exported linux kernel
trees. cvsps uses special semantics for recreating the BK ChangeSet
metadata that has been embedded in the log files for those trees. The
--bkcvs option should only be specified when the cache file is being
created or updated (i.e. initial run of cvsps, or when -u and -x
options are used).
NOTE ON CVS-DIRECT
As of version 2.0b6 cvsps has a partial implementation of the cvs
client code built in. This reduces the RTT and/or handshaking overhead
from one per patchset member to one per patchset. This dramatically
increases the speed of generating diffs over a slow link, and improves
the consistency of operation. Currently the --cvs-direct option turns
on the use of this code, but it very well may be default by the time
2.0 comes out. The built-in cvs code attempts to be compatible with
cvs, but may have problems, which should be reported. It honors the
CVS_RSH and CVS_SERVER environment variables, but does not parse the
~/.cvsrc file.
NOTE ON CVSPS RC FILE
CVSps parses an rc file at startup. This file should be located in
~/.cvsps/cvspsrc. The file should contain arguments, in the exact syn-
tax as the command line, one per line. If an argument takes a parame-
ter, the parameter should be on the same line as the argument.
NOTE ON DATE FORMATS
All dates are reported in localtime. This can be overridden (as usual)
using the TZ environment variable. Dates as arguments must be in the
format 'yyyy/mm/dd hh:mm:ss'; for example,
$ cvsps-d '2004/05/01 00:00:00' -d '2004/07/07 12:00:00'
SEE ALSOcvs(1), ci(1), co(1), cvs(5), cvsbug(8), diff(1), grep(1), patch(1),
rcs(1), rcsdiff(1), rcsmerge(1), rlog(1).
REPORTING BUGS
Report bugs to "David Mansfield <cvsps@dm.cobite.com>"
BUGS
No known bugs.
4
cvsps(1)cvsps(1)
5
