CVSps - create patchset information from CVS


   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>]


   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.


   -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
          tags specified, show revisions between the two tags.

   -p <dir>
          output    individual    patchsets   as   files   in   <dir>   as

   -v     show very verbose parsing messages

   -t     show some brief memory usage statistics

   --norc when invoking cvs, ignore the .cvsrc file

          when multiple  patchset  diffs  are  being  generated,  put  the
          patchset  summary  for  all  patchsets  at  the beginning of the

   --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

          (see note below) for use in parsing the BK->CVS tree log formats
          only.    This   enables  some  hacks  which  are  not  generally

          disable the use of rlog internally.  Note: rlog is required  for
          stable PatchSet numbering.  Use with care.

   --diff-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
          PatchSet 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.

          Operate on the specified repository (overrides working dir.)


   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

   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.


   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.

   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


   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.


   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).


   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.


   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.


   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'


   cvs(1),  ci(1),  co(1),  cvs(5), cvsbug(8), diff(1), grep(1), patch(1),
   rcs(1), rcsdiff(1), rcsmerge(1), rlog(1).


   Report bugs to "David Mansfield <>"


   No known bugs.


More Linux Commands

XQueryTree(3) - query window tree information (Man Page)....
The XQueryTree function returns the root ID, the parent window ID, a pointer to the list of children windows (NULL when there are no children), and the number o

XvGrabPort(3) - lock port for exclusive use by client.......
XvGrabPort(3) grabs a port. Once a client grabs a port, only that client can make video requests to that port. If the time is before the current port time, the

uuid_time(3) - extract the time at which the UUID was create
The uuid_time function extracts the time at which the supplied time-based UUID uu was created. Note that the UUID creation time is only encoded within certain t

clnttcp_create(3) - library routines for remote procedure ca
These routines allow C programs to make procedure calls on other machines across the network. First, the client calls a procedure to send a data packet to the s

wechochar(3ncurses) - add a character (with attributes) to a
The addch, waddch, mvaddch and mvwaddch routines put the character ch into the given window at its current window position, which is then advanced. They are ana

b2m(1) - convert old Emacs Rmail Babyl format to mbox format
b2m accepts Babyl format mail (as used by older versions of Rmail in GNU Emacs) on standard input, and converts it to mbox format on standard output. Babyl was

XGetIMValues(3) - open, close, and obtain input method infor
The XOpenIM function opens an input method, matching the current locale and modifiers specification. Current locale and modifiers are bound to the input method

curses_version(3ncurses) - miscellaneous curses extensions
curses_version.3ncurses - These functions are extensions to the curses library which do not fit easily into other categories. Use curses_version() to get the ve

pppoe.conf(5) Configuration file used by pppoe-start(8), ppp
/etc/ppp/pppoe.conf is a shell script which contains configuration information for Roaring Penguins PPPoE scripts. Note that pppoe.conf is used only by the vari

squid_ldap_group(8) - Squid LDAP external acl group helper
This helper allows Squid to connect to a LDAP directory to authorize users via LDAP groups. LDAP options are specified as parameters on the command line, while

queue(3) - implementations of lists, tail queues, and circul
These macros define and operate on three types of data structures: lists, tail queues, and circular queues. All three structures support the following functiona

getdelim(3) - delimited string input - Linux manual page....
getline() reads an entire line from stream, storing the address of the buffer containing the text into *lineptr. The buffer is null-terminated and includes the

We can't live, work or learn in freedom unless the software we use is free.