summaryrefslogtreecommitdiff
path: root/cvsps.1
diff options
context:
space:
mode:
Diffstat (limited to 'cvsps.1')
-rw-r--r--cvsps.1205
1 files changed, 205 insertions, 0 deletions
diff --git a/cvsps.1 b/cvsps.1
new file mode 100644
index 0000000..cea0faf
--- /dev/null
+++ b/cvsps.1
@@ -0,0 +1,205 @@
+.TH "cvsps" 1
+.SH NAME
+CVSps \- create patchset information from CVS
+.SH SYNOPSIS
+.B cvsps
+[\-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>]
+.SH 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
+'atomically' to the repository.
+.SH OPTIONS
+.TP
+.B \-h
+display usage summary
+.TP
+.B \-x
+ignore (and rebuild) ~/.cvsps/cvsps.cache file
+.TP
+.B \-u
+update ~/.cvsps/cvsps.cache file
+.TP
+.B \-z <fuzz>
+set the timestamp fuzz factor for identifying patch sets
+.TP
+.B \-g
+generate diffs of the selected patch sets
+.TP
+.B \-s <patchset>[\-[<patchset>]][,<patchset>...]
+generate a diff for a given patchsets and patchset ranges
+.TP
+.B \-a <author>
+restrict output to patchsets created by author
+.TP
+.B \-f <file>
+restrict output to patchsets involving file
+.TP
+.B \-d <date1> \-d <date2>
+if just one date specified, show
+revisions newer than date1. If two dates specified,
+show revisions between two dates.
+.TP
+.B \-l <regex>
+restrict output to patchsets matching regex in log message
+.TP
+.B \-b <branch>
+restrict output to patchsets affecting history of branch.
+If you want to restrict to the main branch, use a branch of 'HEAD'.
+.TP
+.B \-r <tag1> \-r <tag2>
+if just one tag specified, show
+revisions since tag1. If two tags specified, show
+revisions between the two tags.
+.TP
+.B \-p <dir>
+output individual patchsets as files in <dir> as <dir>/<patchset>.patch
+.TP
+.B \-v
+show very verbose parsing messages
+.TP
+.B \-t
+show some brief memory usage statistics
+.TP
+.B \-\-norc
+when invoking cvs, ignore the .cvsrc file
+.TP
+.B \-\-summary\-first
+when multiple patchset diffs are being generated, put the patchset
+summary for all patchsets at the beginning of the output.
+.TP
+.B \-\-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
+.TP
+.B \-\-bkcvs
+(see note below) for use in parsing the BK\->CVS tree log formats only. This enables
+some hacks which are not generally applicable.
+.TP
+.B \-\-no\-rlog
+disable the use of rlog internally. Note: rlog is
+required for stable PatchSet numbering. Use with care.
+.TP
+.B \-\-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.
+.TP
+.B \-\-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 PatchSet instead of one per file.
+.TP
+.B \-\-debuglvl <bitmask>
+enable various debug output channels.
+.TP
+.B \-Z <compression>
+A value 1\-9 which specifies amount of compression. A value of 0 disables compression.
+.TP
+.B \-\-root <cvsroot>
+Override the setting of CVSROOT (overrides working dir. and environment). For --cvs-direct only.
+.TP
+.B \-q
+Be quiet about warnings.
+.B \-A
+Show ancestor branch when a new branch is found.
+.TP
+.B \<repository>
+Operate on the specified repository (overrides working dir.)
+.SH "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.
+.PP
+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.
+.PP
+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 summary will indicate which members are which, and diffs will
+be generated accordingly.
+.SH "NOTE ON CVS VERSIONS"
+Among the different cvs subcommands used by cvsps is the 'rlog' command. The
+rlog command is used to get revision history of a module, and it disregards
+the current working directory. The important difference 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 working directory with the '\-P' option. If 'rlog' is not used, these
+files logs will not be parsed, and the PatchSet numbering will be unstable.
+.PP
+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.
+.SH "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 commands (log, diff, and update).
+This is to allow cvsps to function without a completely checked out tree. Because
+these r\-commands are 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.
+.SH "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).
+.SH "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.
+.SH "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 syntax as the command line, one per line.
+If an argument takes a parameter, the parameter should be on the same line as the argument.
+.SH "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,
+.IP "" 4
+$ cvsps -d '2004/05/01 00:00:00' -d '2004/07/07 12:00:00'
+.SH "SEE ALSO"
+.BR cvs ( 1 ),
+.BR ci ( 1 ),
+.BR co ( 1 ),
+.BR cvs ( 5 ),
+.BR cvsbug ( 8 ),
+.BR diff ( 1 ),
+.BR grep ( 1 ),
+.BR patch ( 1 ),
+.BR rcs ( 1 ),
+.BR rcsdiff ( 1 ),
+.BR rcsmerge ( 1 ),
+.BR rlog ( 1 ).
+.SH "REPORTING BUGS"
+Report bugs to "David Mansfield <cvsps@dm.cobite.com>"
+.SH BUGS
+No known bugs.
+