cvsps man page on YellowDog

Man page or keyword search:  
man Server   18644 pages
apropos Keyword Search (all sections)
Output format
YellowDog logo
[printable version]

cvsps(1)							      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-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
	      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.

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

       <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
       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 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)
[top]

List of man pages available for YellowDog

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net