Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
cvsps(1)		     General Commands Manual			cvsps(1)

NAME
     CVSps - create patchset information from CVS

SYNOPSIS
     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-di-
     rect]  [--debuglvl  <bitmask>]  [-Z  <compression>] [--root <cvsroot>] [-q]
     [-A] [<repository>]

DESCRIPTION
     CVSps is a program for generating 'patchset' information from a CVS reposi-
     tory.  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 pic-
     ture of the evolution of a cvs project.  While cvs tracks revision informa-
     tion, 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 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 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 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 applicable.

     --no-rlog
	    disable the use of rlog internally.  Note: rlog is required for sta-
	    ble 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  PatchSet  in-
	    stead 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 environ-
	    ment).  For --cvs-direct only.

     -q     Be quiet about warnings.  -A Show ancestor branch when a new  branch
	    is found.

     <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  ap-
     proach 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 be-
     fore 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 af-
     ter  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  patch-
     sets  as  before  or  after  the tag and the patchset summary 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'	command.
     The rlog command is used to get revision history of a module, and it disre-
     gards  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'  op-
     tion.   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 ver-
     sion 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 commands
     (log, diff, and update).  This is to allow cvsps to function without a com-
     pletely 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 com-
     mand.  However, if the --diff-opts option is specified (to change, for  ex-
     ample, 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 ap-
     plying 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  prob-
     lems, which should be reported.  It honors the CVS_RSH and CVS_SERVER envi-
     ronment 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  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.

NOTE ON DATE FORMATS
     All dates are reported in localtime.  This can be overridden (as usual) us-
     ing 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 ALSO
     cvs(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.

									cvsps(1)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=cvsps&sektion=1&manpath=FreeBSD+Ports+15.1.quarterly>

home | help