Unix/Linux Go Back    

CentOS 7.0 - man page for cvsps (centos section 1)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

cvsps(1)										 cvsps(1)

       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 patch-
       set 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 'atomi-
       cally' 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  speci-
	      fied, 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 <dir>/<patchset>.patch

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

       --test-log <captured cvs log file>
	      for testing changes, you can capture cvs log output, then test  against  this  cap-
	      tured file instead of hammering some poor CVS server

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

	      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  multi-
	      ple requests over a single client, reducing the overhead of handshaking and authen-
	      tication 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  compres-

       --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  revi-
       sion  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 them-
       selves 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 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  direc-
       tory.   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 unsta-

       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.

       Another	important  note  is that cvsps will attempt, whenever possible, to use the r-com-
       mands (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-com-
       mands 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 com-
       mand.  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 envi-
       ronment variable.  Dates as arguments must be in the  format  'yyyy/mm/dd  hh:mm:ss';  for

	   $ 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 <cvsps@dm.cobite.com>"

       No known bugs.

Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 02:02 AM.