Provided by: cvsnt_2.5.03.2382-3.3_i386 bug

NAME

       cvs - Concurrent Versions Sytem

SYNOPSIS

       cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]

NOTE

       This  manpage is written for cvsnt. As it is a replacement for cvs, the
       cvsnt binary is installed as cvs into the system, therefore  all  cvsnt
       commands start with cvs.

       This manpage is a summary of some of the features of cvsnt but for more
       in-depth documentation, consult the cvsnt manual (as described  in  the
       SEE ALSO section of this manpage).

DESCRIPTION

       CVS  is  a version control system, which allows you to keep old version
       of files (usually source code), keep  a  log  of  who,  when,  and  why
       changes   occurred,   etc.,  like  RCS  or  SCCS.  CVS  operates  on  a
       hierarchical collection of directories consisting of version controlled
       files,  called  module. CVS helps to manage releases and to control the
       concurrent editing of source files among multiple authors.  CVS  allows
       triggers to enable/log/control various operations and works well over a
       wide area network.

       cvs keeps a single copy of the master sources. This copy is called  the
       source  ’’repository’’;  it  contains  all  the  information  to permit
       extracting previous software releases at any time  based  on  either  a
       symbolic revision tag, or a date in the past.

ESSENTIAL COMMANDS

       cvs  provides a rich variety of commands (cvs_command in the Synopsis),
       each of which often has a wealth of options, to satisfy the many  needs
       of  source  management in distributed environments.  However, you don’t
       have to master every detail to do useful work with cvs; in  fact,  five
       commands   are  sufficient  to  use  (and  contribute  to)  the  source
       repository.

       cvs checkout modules...
              A necessary preliminary for most cvs work: creates your  private
              copy of the source for modules (named collections of source; you
              can also use a path relative to  the  source  repository  here).
              You  can  work  with  this copy without interfering with others’
              work. At least one subdirectory level is always created.

       cvs update
              Execute this command from within your private  source  directory
              when you wish to update your copies of source files from changes
              that other developers have made to the source in the repository.

       cvs add file...
              Use  this  command  to  enroll  new files in cvs records of your
              working directory. The files will be added to the repository the
              next time you run cvs commit .

              Note:  You  should  use  the cvs import command to bootstrap new
              sources into the source repository.  cvs add is  only  used  for
              new files to an already checked-out module.

       cvs remove file...
              Use  this  command  (after  erasing any files listed) to declare
              that you wish to  eliminate  files  from  the  repository.   The
              removal does not affect others until you run cvs commit .

       cvs commit file...
              Use  this  command  when you wish to ’’publish’’ your changes to
              other  developers,  by  incorporating   them   in   the   source
              repository.

OPTIONS

       The  cvs  command  line  can  include  cvs_options,  which apply to the
       overall cvs program; a cvs_command, which specifies a particular action
       on  the source repository; and command_options and command_arguments to
       fully specify what the cvs_command will do.

       Warning: you must be careful  of  precisely  where  you  place  options
       relative to the cvs_command.  The same option can mean different things
       depending on whether it is in the cvs_options position (to the left  of
       a  cvs  command)  or in the command_options position (to the right of a
       cvs command).

       There are only two situations where you may omit cvs_command: cvs -H or
       cvs  --help  elicits  a  list  of available commands, and cvs -v or cvs
       --version displays version information on cvs itself.

CVS OPTIONS

       cvs supports GNU style long options as well as short  options.  Only  a
       few  long options are currently supported, these are listed in brackets
       after the short options whose functions they duplicate.

       Use these options to control the overall cvs program:

       -H [ --help ]
              Display usage information about the specified  cvs_command  (but
              do  not  actually  execute  the command). If you don’t specify a
              command name, cvs -H displays a  summary  of  all  the  commands
              available.

       -Q     Causes the command to be really quiet; the command will generate
              output only for serious problems.

       -q     Causes the command to be somewhat quiet; informational messages,
              such   as  reports  of  recursion  through  subdirectories,  are
              suppressed.

       -b bindir
              Use bindir as the directory where RCS programs are located  (CVS
              1.9  and older). Overrides the setting of the RCSBIN environment
              variable.  This  value  should  be  specified  as  an   absolute
              pathname.

       -d CVS_root_directory
              Use  CVS_root_directory  as  the  root directory pathname of the
              master source repository. Overrides the setting of  the  CVSROOT
              environment  variable.  This  value  should  be  specified as an
              absolute pathname.

       -D CVS_prefix_directory
              Use  CVS_prefix_directory  as  the  filename   prefix   to   all
              repositories.  This  value  should  be  specified as an absolute
              pathname.

       -e editor
              Use editor to enter  revision  log  information.  Overrides  the
              setting   of  the  CVSEDITOR,  VISUAL,  and  EDITOR  environment
              variables.

       -f     Do not read the cvs startup file (~/.cvsrc).

       -l     Do not log the cvs_command in the command history  (but  execute
              it  anyway).  See  the  description  of  the history command for
              information on command history.

       -n     Do not change any files. Attempt to execute the cvs_command, but
              only  to  issue  reports;  do  not  remove, update, or merge any
              existing files, or create any new files.

       -t     Trace program execution; display messages showing the  steps  of
              cvs  activity.  Particularly  useful  with  -n  to  explore  the
              potential impact of an unfamiliar command.

       -r     Makes new working files read-only. Same effect as if the CVSREAD
              environment variable is set.

       -v [ --version ]
              Displays version and copyright information for cvs.

       -w     Makes  new  working  files  read-write  (default). Overrides the
              setting of the CVSREAD environment variable.

       -x     Encrypt all communication between the client and the server.  As
              of  this writing, this is only implemented when using a Kerberos
              connection.

       -z compression-level
              When  transferring  files  across  the  network  use  gzip  with
              compression  level compression-level to compress and de-compress
              data as it is transferred. Requires the presence of the GNU gzip
              program in the current search path at both ends of the link.

USAGE

       Except  when  requesting  general  help  with cvs -H you must specify a
       cvs_command to cvs to select a specific  release  control  function  to
       perform.  Each  cvs  command  accepts its own collection of options and
       arguments. However, many options are available across several commands.
       You  can  display a usage summary for each command by specifying the -H
       option with the command.

CVS STARTUP FILE

       Normally, when CVS starts up, it reads the .cvsrc file  from  the  home
       directory  of the user reading it. This startup procedure can be turned
       off with the -f flag.  The .cvsrc file lists CVS commands with  a  list
       of  arguments, one command per line. For example, the following line in
       .cvsrc: diff -c will mean that the cvs  diff  command  will  always  be
       passed  the  -c  option  in  addition  to  any  other  options that are
       specified in the command line (in this case it will have the effect  of
       producing context sensitive diffs for all executions of cvs diff ).

CVS COMMAND SUMMARY

       Here are brief descriptions of all the cvs commands:

       add    Add  a  new  file  or directory to the repository, pending a cvs
              commit on the same file. Can only be done  from  within  sources
              created by a previous cvs checkout invocation. Use cvs import to
              place whole new hierarchies of sources under cvs control.  (Does
              not directly affect repository; changes working directory.)

       admin  Execute  control  functions  on  the source repository. (Changes
              repository directly; uses  working  directory  without  changing
              it.)

       checkout
              Make  a  working directory of source files for editing. (Creates
              or changes working directory.)

       commit Apply to the source repository changes, additions, and deletions
              from your working directory. (Changes repository.)

       diff   Show  differences  between files in working directory and source
              repository, or between two revisions in source repository. (Does
              not change either repository or working directory.)

       export Prepare  copies  of a set of source files for shipment off site.
              Differs  from  cvs  checkout  in  that  no  cvs   administrative
              directories  are  created  (and  therefore  cvs commit cannot be
              executed from a directory prepared with  cvs  export  ),  and  a
              symbolic  tag  must  be  specified. (Does not change repository;
              creates directory similar to working directories).

       history
              Show reports on cvs commands that you or others have executed on
              a  particular  file or directory in the source repository. (Does
              not change repository or working directory.)  History  logs  are
              kept only if enabled by creation of the $CVSROOT/CVSROOT/history
              file; see cvsnt(5).

       import Incorporate a set of  updates  from  off-site  into  the  source
              repository, as a ’’vendor branch’’. (Changes repository.)

       init   Initialize  a  repository by adding the CVSROOT subdirectory and
              some default  control  files.  You  must  use  this  command  or
              initialize  the  repository in some other way before you can use
              it.

       log    Display log information. (Does not change repository or  working
              directory.)

       rdiff  Prepare  a  collection  of  diffs  as  a  patch file between two
              releases in the  repository.  (Does  not  change  repository  or
              working directory.)

       release
              Cancel  a  cvs  checkout  ,  abandoning any changes. (Can delete
              working directory; no effect on repository.)

       remove Remove files from the source repository, pending a cvs commit on
              the  same  files.  (Does not directly affect repository; changes
              working directory.)

       rtag   Explicitly specify a symbolic tag for  particular  revisions  of
              files  in  the  source  repository. See also cvs tag .  (Changes
              repository  directly;  does  not  require  or   affect   working
              directory.)

       status Show current status of files: latest version, version in working
              directory,  whether  working  version  has  been   edited   and,
              optionally,  symbolic  tags  in  the  RCS file. (Does not change
              repository or working directory.)

       tag    Specify a symbolic tag for files in the repository. By  default,
              tags the revisions that were last synchronized with your working
              directory. (Changes repository directly; uses working  directory
              without changing it.)

       update Bring  your  working  directory up to date with changes from the
              repository. Merges are performed automatically when possible;  a
              warning   is   issued  if  manual  resolution  is  required  for
              conflicting changes. (Changes working directory; does not change
              repository.)

COMMON COMMAND OPTIONS

       This  section  describes  the command_options that are available across
       several cvs commands. Not all commands support all  of  these  options;
       each  option  is  only  supported  for  commands  where it makes sense.
       However, when a command has one of these options you can count  on  the
       same  meaning  for  the  option  as  in  other commands. (Other command
       options, which are  listed  with  the  individual  commands,  may  have
       different meanings from one cvs command to another.)

       Warning:  the history command is an exception; it supports many options
       that conflict even with these standard options.

       -D date_spec
              Use the most recent revision no later than date_spec  (a  single
              argument,  date  description  specifying  a date in the past). A
              wide variety of date formats are supported,  in  particular  ISO
              ("1972-09-24 20:05") or Internet ("24 Sep 1972 20:05").

       The  date_spec  is interpreted as being in the local timezone, unless a
       specific timezone is specified. The specification  is  ’’sticky’’  when
       you  use  it to make a private copy of a source file; that is, when you
       get a working file using -D, cvs records the  date  you  specified,  so
       that  further  updates  in  the  same  directory will use the same date
       (unless you explicitly override it; see the description of  the  update
       command).   -D  is  available with the checkout, diff, history, export,
       rdiff,  rtag,  and   update   commands.    Examples   of   valid   date
       specifications include:
                 1 month ago
                 2 hours ago
                 400000 seconds ago
                 last year
                 last Monday
                 yesterday
                 a fortnight ago
                 3/31/92 10:00:07 PST
                 January 23, 1987 10:05pm
                 22:00 GMT

       -f     When  you specify a particular date or tag to cvs commands, they
              normally ignore files that do not contain the tag  (or  did  not
              exist  on the date) that you specified. Use the -f option if you
              want files retrieved even when there is no match for the tag  or
              date.  (The  most recent version is used in this situation.)  -f
              is available with these commands: checkout, export, rdiff, rtag,
              and update.

       -k kflag
              Alter  the  default  processing  of  keywords.  The -k option is
              available with the  add,  checkout,  diff,  export,  rdiff,  and
              update  commands.   Your  kflag specification is ’’sticky’’ when
              you use it to create a private copy of a source file;  that  is,
              when  you  use this option with the checkout or update commands,
              cvs associates your selected kflag with the file, and  continues
              to use it with future update commands on the same file until you
              specify otherwise.  Some of the more useful kflags are  -ko  and
              -kb  (for  binary  files), and -kv which is useful for an export
              where you wish to retain keyword information after an import  at
              some other site.

       -l     Local;  run  only  in  current  working  directory,  rather than
              recurring through subdirectories. Available with  the  following
              commands:  checkout,  commit, diff, export, remove, rdiff, rtag,
              status, tag, and update.

              Warning: This is not the same as  the  overall  cvs  -l  option,
              which you can specify to the left of a cvs command!

       -n     Do  not  run  any checkout/commit/tag/update program. (A program
              can be specified to run on each  of  these  activities,  in  the
              modules  database;  this option bypasses it.) Available with the
              checkout, commit, export, and rtag commands.

              Warning: This is not the same as  the  overall  cvs  -n  option,
              which you can specify to the left of a cvs command!

       -P     Prune  (remove)  directories that are empty after being updated,
              on checkout, or update.  Normally, an empty directory (one  that
              is  void of revision-controlled files) is left alone. Specifying
              -P will cause these directories to be silently removed from your
              checked-out sources. This does not remove the directory from the
              repository, only from your checked  out  copy.  Note  that  this
              option  is  implied  by  the  -r  or  -D options of checkout and
              export.

       -p     Pipe the files retrieved from the repository to standard output,
              rather  than  writing  them  in the current directory. Available
              with the checkout and update commands.

       -r tag Use the revision specified by the tag argument  instead  of  the
              default  ’’head’’  revision.  As  well as arbitrary tags defined
              with the tag or  rtag  command,  two  special  tags  are  always
              available:

              HEAD  refers  to  the  most  recent  version  available  in  the
              repository, and

              BASE refers to the  revision  you  last  checked  out  into  the
              current working directory.

              The  tag  specification  is  ’’sticky’’ when you use this option
              with cvs checkout or cvs update to make your own copy of a file:
              cvs  remembers  the tag and continues to use it on future update
              commands, until you specify otherwise.   tag  can  be  either  a
              symbolic  or  numeric tag. Specifying the -q global option along
              with the -r command option is  often  useful,  to  suppress  the
              warning  messages  when  the  RCS  file  does  not  contain  the
              specified tag.  -r is available with the checkout, commit, diff,
              history, export, rdiff, rtag, and update commands.

              Warning:  This  is  not  the  same as the overall cvs -r option,
              which you can specify to the left of a cvs command!

CVS COMMANDS

       Here (finally) are details on all the cvs commands and the options each
       accepts.  The  summary  lines  at the top of each command’s description
       highlight three kinds of things:

           Command Options and Arguments
                 Special options are described in detail below; common command
                 options may appear only in the summary line.

           Working Directory, or Repository?
                 Some  cvs  commands  require  a working directory to operate;
                 some require a repository.  Also, some  commands  change  the
                 repository,  some  change  the  working  directory,  and some
                 change nothing.

           Synonyms
                 Many commands have synonyms, which you  may  find  easier  to
                 remember (or type) than the principal name.

       add [-k kflag] [-mmessage] files...
              Requires: repository, working directory.
              Changes: working directory.
              Synonym: new
              Use  the  add  command  to create a new file or directory in the
              source repository. The files or directories specified  with  add
              must  already  exist  in  the current directory (which must have
              been created with the checkout command).  To  add  a  whole  new
              directory hierarchy to the source repository (for example, files
              received from a third-party vendor), use the cvs import  command
              instead.

              If the argument to cvs add refers to an immediate sub-directory,
              the directory is created at the  correct  place  in  the  source
              repository,  and  the  necessary  cvs  administration  files are
              created in your working  directory.  If  the  directory  already
              exists  in  the  source  repository,  cvs  add still creates the
              administration files in your  version  of  the  directory.  This
              allows  you to use cvs add to add a particular directory to your
              private sources even if  someone  else  created  that  directory
              after your checkout of the sources. You can do the following:

                        example% mkdir new_directory
                        example% cvs add new_directory
                        example% cvs update new_directory

              An alternate approach using cvs update might be:

                        example% cvs update -d new_directory

              (To add any available new directories to your working directory,
              it’s probably simpler to use cvs checkout or cvs update -d .)

              The added files are not placed in the  source  repository  until
              you use cvs commit to make the change permanent. Doing a cvs add
              on a file that was removed with  the  cvs  remove  command  will
              resurrect the file, if no cvs commit command intervened.

              You  will  have the opportunity to specify a logging message, as
              usual, when you use cvs commit to make the new  file  permanent.
              If  you’d  like  to have another logging message associated with
              just creation of the file (for example, to describe  the  file’s
              purpose),  you  can specify it with the -m message option to the
              add command.

              The -k kflag option specifies the default  way  that  this  file
              will  be  checked  out.  The kflag argument is stored in the RCS
              file and can be changed with cvs  admin  .   Specifying  -ko  is
              useful  for  checking  in  binaries that shouldn’t have keywords
              expanded.

       admin [rcs-options] files...
              Requires: repository, working directory.
              Changes: repository.
              Synonym: rcs
              This is the cvs interface to assorted administrative facilities,
              similar  to  rcs(1).  This command works recursively, so extreme
              care should be used.

       checkout [options] modules...
              Requires: repository.
              Changes: working directory.
              Synonyms: co, get
              Make a working directory containing copies of the  source  files
              specified  by  modules.   You  must  execute cvs checkout before
              using most of the other cvs commands, since most of them operate
              on your working directory.

              modules  are  either  symbolic  names (themselves defined as the
              module modules in the source repository; see cvsnt(5)) for  some
              collection   of  source  directories  and  files,  or  paths  to
              directories or files in the repository.

              Depending on the modules you specify, checkout  may  recursively
              create directories and populate them with the appropriate source
              files. You  can  then  edit  these  source  files  at  any  time
              (regardless  of  whether  other  software developers are editing
              their own copies of the sources); update  them  to  include  new
              changes  applied  by  others to the source repository; or commit
              your work as a permanent change to the repository.

              Note that checkout is used to create directories. The  top-level
              directory  created  is  always  added  to  the  directory  where
              checkout is invoked, and  usually  has  the  same  name  as  the
              specified  module.   In  the case of a module alias, the created
              sub-directory may have a different name, but  you  can  be  sure
              that it will be a sub-directory, and that checkout will show the
              relative path leading to each file as it is extracted into  your
              private work area (unless you specify the -Q global option).

              Running  cvs checkout on a directory that was already built by a
              prior checkout is also permitted, and has  the  same  effect  as
              specifying  the -d option to the update command described below.

              The options permitted with cvs  checkout  include  the  standard
              command  options  -P,  -f, -k kflag , -l, -n, -p, -r tag, and -D
              date.

              In addition to those, you can use these special command  options
              with checkout:

              Use  the  -A  option  to  reset  any  sticky  tags, dates, or -k
              options. (If you get a working file using one of the -r, -D,  or
              -k  options, cvs remembers the corresponding tag, date, or kflag
              and continues using it on future updates; use the -A  option  to
              make  cvs forget these specifications, and retrieve the ’’head’’
              version of the file).

              The -j  branch  option  merges  the  changes  made  between  the
              resulting  revision  and the revision that it is based on (e.g.,
              if the tag refers to a branch, cvs will merge all  changes  made
              in that branch into your working file).

              With  two  -j options, cvs will merge in the changes between the
              two respective revisions. This  can  be  used  to  ’’remove’’  a
              certain delta from your working file.

              In  addition,  each  -j  option  can  contain  on  optional date
              specification which, when used  with  branches,  can  limit  the
              chosen  revision to one within a specific date. An optional date
              is specified by adding a colon (:) to the tag. An example  might
              be  what  cvs import tells you to do when you have just imported
              sources that have conflicts with local changes:
                        example% cvs checkout -jTAG:yesterday -jTAG module

              Use the -N option with -d dir to avoid shortening  module  paths
              in your working directory. (Normally, cvs shortens paths as much
              as possible when you specify an explicit target directory.)

              Use the -c option to  copy  the  module  file,  sorted,  to  the
              standard  output,  instead of creating or modifying any files or
              directories in your working directory.

              Use the -d dir option to create a directory called dir  for  the
              working  files,  instead  of  using the module name.  Unless you
              also use -N, the paths created under dir will  be  as  short  as
              possible.

              Use  the  -s  option  to  display  per-module status information
              stored with the -s option within the modules file.

       commit [-lnR] [-mlog_message’ | -f file] [-r revision] [files...]
              Requires: working directory, repository.
              Changes: repository.
              Synonym: ci
              Use cvs commit when you want to incorporate  changes  from  your
              working source files into the general source repository.

              If  you  don’t  specify  particular  files to commit, all of the
              files in your working current directory are examined.  commit is
              careful  to  change  in the repository only those files that you
              have really changed. By default (or if  you  explicitly  specify
              the  -R  option),  files in subdirectories are also examined and
              committed if they have changed; you can use  the  -l  option  to
              limit  commit  to  the current directory only. Sometimes you may
              want to  force  a  file  to  be  committed  even  though  it  is
              unchanged; this is achieved with the -f flag, which also has the
              effect of disabling recursion (you can turn it back on  with  -R
              of course).

              commit  verifies that the selected files are up to date with the
              current revisions in the source repository; it will notify  you,
              and  exit without committing, if any of the specified files must
              be made current first with cvs update .  commit  does  not  call
              the update command for you, but rather leaves that for you to do
              when the time is right.

              When all is well, an editor is invoked to allow you to  enter  a
              log message that will be written to one or more logging programs
              and placed in  the  source  repository  file.  You  can  instead
              specify  the log message on the command line with the -m option,
              thus suppressing the editor invocation, or use the -F option  to
              specify that the argument file contains the log message.

              The  -r option can be used to commit to a particular symbolic or
              numeric revision. For example, to bring all your files up to the
              revision  ’’3.0’’  (including  those  that haven’t changed), you
              might do:

                        example% cvs commit -r3.0

              Note: This is highly discouraged as the revision numbers are cvs
              internal and may disappear in later versions of cvsnt.

              cvs  will  only allow you to commit to a revision that is on the
              main trunk (a revision with a single dot). However, you can also
              commit  to  a  branch  revision  (one that has an even number of
              dots) with the -r option.  To  create  a  branch  revision,  one
              typically  use the -b option of the rtag or tag commands.  Then,
              either checkout or update can be used to base  your  sources  on
              the newly created branch. From that point on, all commit changes
              made within these working sources will be automatically added to
              a  branch revision, thereby not perturbing main-line development
              in any way. For example, if you had to create a patch to the 1.2
              version  of  the product, even though the 2.0 version is already
              under development, you might do:

                        example% cvs rtag -b -rFCS1_2 FCS1_2_Patch product_module
                        example% cvs checkout -rFCS1_2_Patch product_module
                        example% cd product_module
                        [[ hack away ]]
                        example% cvs commit

              Say  you  have  been  working  on  some  extremely  experimental
              software,  based  on  whatever revision you happened to checkout
              last week. If others in your group would like to  work  on  this
              software with you, but without disturbing main-line development,
              you could commit your change to a new branch.  Others  can  then
              checkout your experimental stuff and utilize the full benefit of
              cvs conflict resolution. The scenario might look like:

                        example% cvs tag -b EXPR1
                        example% cvs update -rEXPR1
                        [[ hack away ]]
                        example% cvs commit

              Others would simply do cvs checkout -rEXPR1  whatever_module  to
              work with you on the experimental change.

       diff  [-kl]  [rcsdiff_options]  [[-r  rev1  |  -D  date1] [-r rev2 | -D
       date2]] [files...]
              Requires: working directory, repository.
              Changes: nothing.
              You  can compare your working files with revisions in the source
              repository, with the cvs diff command. If you  don’t  specify  a
              particular  revision, your files are compared with the revisions
              they were based on. You can also use the  standard  cvs  command
              option -r to specify a particular revision to compare your files
              with. Finally, if you use -r  twice,  you  can  see  differences
              between two revisions in the repository. You can also specify -D
              options to diff against a revision in the past. The  -r  and  -D
              options  can  be  mixed  together  with at most two options ever
              specified.

              See rcsdiff(1) for a list of other accepted options.

              If you don’t specify any files, diff  will  display  differences
              for   all   those  files  in  the  current  directory  (and  its
              subdirectories, unless you use  the  standard  option  -l)  that
              differ  from the corresponding revision in the source repository
              (i.e. files that you have changed),  or  that  differ  from  the
              revision specified.

       export [-flNnQq] -r rev|-D date [-d dir] [-k kflag] module...
              Requires: repository.
              Changes: current directory.
              This command is a variant of cvs checkout ; use it when you want
              a copy of the source for module without the  cvs  administrative
              directories.  For  example,  you might use cvs export to prepare
              source for shipment off-site. This  command  requires  that  you
              specify  a date or tag (with -D or -r), so that you can count on
              reproducing the source you ship to others.

              The only non-standard options are -d dir (write the source  into
              directory  dir)  and -N (don’t shorten module paths). These have
              the same meanings as the same options in cvs checkout .

              The -kv option is useful when export is used.  This  causes  any
              keywords  to  be expanded such that an import done at some other
              site will not  lose  the  keyword  revision  information.  Other
              kflags may be used with cvs export and are described in co(1).

       history [-report] [-flags] [-options args] [files...]
              Requires: the file $CVSROOT/CVSROOT/history
              Changes: nothing.
              cvs  keeps  a history file that tracks each use of the checkout,
              commit, rtag, update, and release  commands.  You  can  use  cvs
              history to display this information in various formats.

              Warning:  cvs  history  uses  -f,  -l,  -n,  and -p in ways that
              conflict with the descriptions in COMMON COMMAND OPTIONS

              Several options (shown above as -report) control  what  kind  of
              report is generated:

             -c  Report  on  each  time  commit  was used (i.e., each time the
                 repository was modified).

             -m module
                 Report on a particular module. (You can meaningfully  use  -m
                 more than once on the command line.)

             -o  Report on checked-out modules.

             -T  Report on all tags.

             -x type
                 Extract  a  particular  set  of  record  types X from the cvs
                 history. The types are indicated by single letters, which you
                 may  specify  in  combination. Certain commands have a single
                 record type: checkout (type ‘O’),  release  (type  ‘F’),  and
                 rtag  (type ‘T’). One of four record types may result from an
                 update: ‘W’, when the working  copy  of  a  file  is  deleted
                 during update (because it was gone from the repository); ‘U’,
                 when a working file was copied from the repository; ‘G’, when
                 a merge was necessary and it succeeded; and ’C’, when a merge
                 was necessary but collisions were detected (requiring  manual
                 merging).  Finally,  one  of  three record types results from
                 commit: ‘M’, when a file was modified; ‘A’, when  a  file  is
                 first added; and ‘R’, when a file is removed.

             -e  Everything  (all  record  types);  equivalent  to  specifying
                 -xMACFROGWUT

             -z zone
                 Use time zone zone when outputting history records. The  zone
                 name  LT  stands  for  local  time; numeric offsets stand for
                 hours and minutes ahead of UTC. For example, +0530 stands for
                 5 hours and 30 minutes ahead of (i.e. east of) UTC.

            The options shown as -flags constrain the report without requiring
            option arguments:

             -a  Show data for all users (the default is to show data only for
                 the user executing cvs history).

             -l  Show last modification only.

             -w  Show  only  the  records for modifications done from the same
                 working directory where cvs history is executing.

            The options shown as -options args constrain the report  based  on
            an argument:

             -b str
                 Show  data  back  to  a  record  containing the string str in
                 either the module name, the  file  name,  or  the  repository
                 path.

             -D date
                 Show data since date.

             -p repository
                 Show data for a particular source repository (you can specify
                 several -p options on the same command line).

             -r rev
                 Show records referring to revisions since the revision or tag
                 named  rev  appears in individual RCS files. Each RCS file is
                 searched for the revision or tag.

             -t tag
                 Show records since tag tag was  last  added  to  the  history
                 file.  This  differs  from the -r flag above in that it reads
                 only the history file, not the RCS files, and is much faster.

             -u name
                 Show records for user name.

       import [-options] repository vendortag releasetag...
                 Requires: Repository, source distribution directory.
                 Changes: repository.
                 Use  cvs  import to incorporate an entire source distribution
                 from an outside source (e.g.,  a  source  vendor)  into  your
                 source  repository  directory.  You can use this command both
                 for initial creation  of  a  repository,  and  for  wholesale
                 updates to the module form the outside source.

                 The  repository argument gives a directory name (or a path to
                 a directory) under the CVS root directory  for  repositories;
                 if the directory did not exist, import creates it.

                 When  you  use  import  for  updates  to source that has been
                 modified in your source repository (since a prior import), it
                 will  notify  you  of  any  files  that  conflict  in the two
                 branches of development; use cvs checkout -j to reconcile the
                 differences, as import instructs you to do.

                 By  default, certain file names are ignored during cvs import
                 names associated  with  CVS  administration,  or  with  other
                 common  source control systems; common names for patch files,
                 object files, archive files, and  editor  backup  files;  and
                 other names that are usually artifacts of assorted utilities.
                 For an up to date list of ignored file names, see  the  cvsnt
                 manual  (as  described  in  the  SEE  ALSO  section  of  this
                 manpage).

                 The outside source is  saved  in  a  first-level  branch,  by
                 default  1.1.1  .   Updates  are  leaves  of this branch; for
                 example, files from the first imported collection  of  source
                 will be revision 1.1.1.1 , then files from the first imported
                 update will be revision 1.1.1.2 , and so on.

                 At least three arguments are required. repository  is  needed
                 to  identify the collection of source. vendortag is a tag for
                 the entire branch (e.g., for 1.1.1). You must also specify at
                 least  one  releasetag  to  identify  the files at the leaves
                 created each time you execute cvs import .

                 One of the standard cvs  command  options  is  available:  -m
                 message.  If  you  do  not specify a logging message with -m,
                 your editor is invoked (as with commit) to allow you to enter
                 one.

                 There are three additional special options.

                 Use  -d to specify that each file’s time of last modification
                 should be used for the checkin date and time.

                 Use -b branch to specify  a  first-level  branch  other  than
                 1.1.1.

                 Use  -I  name  to  specify  file names that should be ignored
                 during import. You can use this option repeatedly.  To  avoid
                 ignoring  any  files  at all (even those ignored by default),
                 specify -I !.

       log [-l] rlog-options [files...]
                 Requires: repository, working directory.
                 Changes: nothing.
                 Synonym: rlog
                 Display log information for  files.  Among  the  more  useful
                 options  are  -h  to  display  only the header (including tag
                 definitions, but omitting most of the full log); -r to select
                 logs  on  particular revisions or ranges of revisions; and -d
                 to select particular dates or date ranges.  See  rlog(1)  for
                 full  explanations.  This  command  is  recursive by default,
                 unless the -l option is specified.

       rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
                 Requires: repository.
                 Changes: nothing.
                 Synonym: patch
                 Builds  a  Larry  Wall  format  patch(1)  file  between   two
                 releases,  that can be fed directly into the patch program to
                 bring an old release up-to-date with the new  release.  (This
                 is  one  of  the few cvs commands that operates directly from
                 the repository, and doesn’t require a prior  checkout.)   The
                 diff  output  is  sent to the standard output device. You can
                 specify  (using  the  standard  -r  and   -D   options)   any
                 combination  of  one  or  two revisions or dates. If only one
                 revision or  date  is  specified,  the  patch  file  reflects
                 differences  between  that  revision  or date and the current
                 ’’head’’ revisions in the RCS file.

                 Note that if the software release affected  is  contained  in
                 more  than one directory, then it may be necessary to specify
                 the -p option to the patch  command  when  patching  the  old
                 sources,  so  that  patch  is able to find the files that are
                 located in other directories.

                 The standard option flags -f, and -l are available with  this
                 command.  There are also several special options flags:

                 If  you  use  the  -s  option,  no  patch output is produced.
                 Instead, a summary of the changed or added files between  the
                 two  releases  is sent to the standard output device. This is
                 useful for finding out, for example, which files have changed
                 between two dates or revisions.

                 If  you use the -t option, a diff of the top two revisions is
                 sent to the standard output device. This is most  useful  for
                 seeing what the last change to a file was.

                 If  you  use  the  -u option, the patch output uses the newer
                 ’’unidiff’’ format for context diffs.

                 You can use -c to explicitly specify  the  diff  -c  form  of
                 context diffs (which is the default), if you like.

       release [-dQq] modules...
                 Requires: Working directory.
                 Changes: Working directory, history log.
                 This  command  is  meant  to  safely cancel the effect of cvs
                 checkout .  Since cvs doesn’t lock files, it  isn’t  strictly
                 necessary  to  use this command. You can always simply delete
                 your working directory, if you  like;  but  you  risk  losing
                 changes you may have forgotten, and you leave no trace in the
                 cvs history file that you’ve abandoned your checkout.

                 Use cvs release to avoid these problems. This command  checks
                 that  no  un-committed  changes  are  present;  that  you are
                 executing it from immediately above, or inside, a cvs working
                 directory; and that the repository recorded for your files is
                 the same as the repository defined in the module database.

                 If all these conditions are true, cvs release leaves a record
                 of  its execution (attesting to your intentionally abandoning
                 your checkout) in the cvs history log.

                 You can use the -d flag to request that your  working  copies
                 of the source files be deleted if the release succeeds.

       remove [-lR] [files...]
                 Requires: Working directory.
                 Changes: Working directory.
                 Synonyms: rm, delete
                 Use  this  command  to  declare that you wish to remove files
                 from the source  repository.  Like  most  cvs  commands,  cvs
                 remove works on files in your working directory, not directly
                 on the repository. As a safeguard, it also requires that  you
                 first  erase the specified files from your working directory.

                 The files are not  actually  removed  until  you  apply  your
                 changes  to  the  repository  with commit; at that point, the
                 corresponding RCS files in the source  repository  are  moved
                 into the Attic directory (also within the source repository).

                 Note: cvsnt does no longer move  the  files  into  the  Attic
                 directory,  but  leaves them in the directory, and marks them
                 ’’DEAD’’.

                 This  command  is  recursive  by  default,   scheduling   all
                 physically  removed  files  that  it finds for removal by the
                 next commit.  Use the -l option to avoid this  recursion,  or
                 just  specify  that  actual  files  that  you  wish remove to
                 consider.

       rtag [-falnRQq] [-b] [-d] [-r tag | -D date] symbolic_tag modules...
                 Requires: repository.
                 Changes: repository.
                 Synonym: rfreeze
                 You  can  use  this  command  to  assign  symbolic  tags   to
                 particular,  explicitly  specified  source  versions  in  the
                 repository.   cvs  rtag  works  directly  on  the  repository
                 contents  (and  requires  no  prior  checkout).   Use cvs tag
                 instead, to base the selection of  versions  to  tag  on  the
                 contents of your working directory.

                 In  general,  tags  (often  the  symbolic  names  of software
                 distributions) should not be removed, but the  -d  option  is
                 available  as  a means to remove completely obsolete symbolic
                 names if necessary  (as  might  be  the  case  for  an  Alpha
                 release, say).

                 cvs rtag will not move a tag that already exists. With the -F
                 option, however, cvs rtag  will  re-locate  any  instance  of
                 symbolic_tag  that  already  exists  on  that file to the new
                 repository versions. Without the -F option, attempting to use
                 cvs rtag to apply a tag that already exists on that file will
                 produce an error message.

                 The -b option  makes  the  tag  a  ’’branch’’  tag,  allowing
                 concurrent,  isolated  development.  This  is most useful for
                 creating  a  patch  to   a   previously   released   software
                 distribution.

                 You  can use the standard -r and -D options to tag only those
                 files that already contain a certain tag.  This method  would
                 be used to rename a tag: tag only the files identified by the
                 old tag, then delete the old tag,  leaving  the  new  tag  on
                 exactly the same files as the old tag.

                 rtag   executes   recursively   by   default,   tagging   all
                 subdirectories of modules you specify in  the  argument.  You
                 can  restrict its operation to top-level directories with the
                 standard -l option; or you can explicitly  request  recursion
                 with -R.

                 The  modules  database  can  specify  a  program  to  execute
                 whenever a tag  is  specified;  a  typical  use  is  to  send
                 electronic mail to a group of interested parties. If you want
                 to bypass that program, use the standard -n option.

                 Use the -a option to have rtag look in the Attic for  removed
                 files that contain the specified tag. The tag is removed from
                 these files, which makes it convenient to re-use  a  symbolic
                 tag  as development continues (and files get removed from the
                 up-coming distribution).

       status [-lRqQ] [-v] [files...]
                 Requires: working directory, repository.
                 Changes: nothing.
                 Display a brief report on the current status  of  files  with
                 respect  to  the  source repository, including any ’’sticky’’
                 tags, dates, or -k options. (’’Sticky’’ options will restrict
                 how  cvs  update  operates  until  you  reset  them;  see the
                 description of cvs update -A....)

                 You can also use this command  to  anticipate  the  potential
                 impact  of  a cvs update on your working source directory. If
                 you do not specify any files explicitly,  reports  are  shown
                 for  all files that cvs has placed in your working directory.
                 You can limit  the  scope  of  this  search  to  the  current
                 directory  itself  (not its subdirectories) with the standard
                 -l option flag;  or  you  can  explicitly  request  recursive
                 status reports with the -R option.

                 The -v option causes the symbolic tags for the RCS file to be
                 displayed as well.

       tag [-lQqR] [-F] [-b]  [-d]  [-r  tag  |  -D  date]  [-f]  symbolic_tag
       [files...]
                 Requires: working directory, repository.
                 Changes: repository.
                 Synonym: freeze
                 Use this command to  assign  symbolic  tags  to  the  nearest
                 repository  versions  to  your  working sources. The tags are
                 applied immediately to the repository, as with rtag.

                 One use for tags is to record a ’’snapshot’’ of  the  current
                 sources  when  the software freeze date of a project arrives.
                 As bugs are fixed after the freeze date, only  those  changed
                 sources that are to be part of the release need be re-tagged.

                 The symbolic tags  are  meant  to  permanently  record  which
                 revisions  of  which  files  were used in creating a software
                 distribution. The checkout, export and update commands  allow
                 you  to extract an exact copy of a tagged release at any time
                 in the future, regardless of whether files have been changed,
                 added, or removed since the release was tagged.

                 You  can use the standard -r and -D options to tag only those
                 files that already contain a certain tag. This  method  would
                 be used to rename a tag: tag only the files identified by the
                 old tag, then delete the old tag,  leaving  the  new  tag  on
                 exactly the same files as the old tag.

                 Specifying the -f flag in addition to the -r or -D flags will
                 tag those files named on the command line even if they do not
                 contain the old tag or did not exist on the specified date.

                 By  default  (without  a  -r  or  -D flag) the versions to be
                 tagged are supplied implicitly by the  cvs  records  of  your
                 working files’ history rather than applied explicitly.

                 If  you use cvs tag -d symbolic_tag... , the symbolic tag you
                 specify is deleted instead of being added.

                 Warning: Be very certain of your ground before you  delete  a
                 tag;   doing   this   effectively  discards  some  historical
                 information, which may later turn out to have been  valuable.

                 cvs  tag will not move a tag that already exists. With the -F
                 option, however, cvs  tag  will  re-locate  any  instance  of
                 symbolic_tag  that  already  exists  on  that file to the new
                 repository versions. Without the -F option, attempting to use
                 cvs  tag to apply a tag that already exists on that file will
                 produce an error message.

                 The -b option  makes  the  tag  a  ’’branch’’  tag,  allowing
                 concurrent,  isolated  development.  This  is most useful for
                 creating  a  patch  to   a   previously   released   software
                 distribution.

                 Normally,  tag  executes  recursively through subdirectories;
                 you can prevent this by using  the  standard  -l  option,  or
                 specify the recursion explicitly by using -R.

       update [-ACdflPpQqR] [-d] [-r tag|-D date] files...
                 Requires: repository, working directory.
                 Changes: working directory.
                 After  you’ve  run  checkout  to  create your private copy of
                 source from the  common  repository,  other  developers  will
                 continue changing the central source. From time to time, when
                 it is convenient in your development process, you can use the
                 update   command   from  within  your  working  directory  to
                 reconcile your work with any revisions applied to  the source
                 repository since your last checkout or update.

                 update  keeps you informed of its progress by printing a line
                 for each file, prefaced with one of the characters U A R M  C
                 ?  to indicate the status of the file:

       U file    The  file  was  brought  up  to  date  with  respect  to  the
                 repository. This is done for any  file  that  exists  in  the
                 repository  but  not  in  your source, and for files that you
                 haven’t  changed  but  are  not  the  most  recent   versions
                 available in the repository.

       A file    The  file has been added to your private copy of the sources,
                 and will be added to the source repository when you  run  cvs
                 commit  on  the file. This is a reminder to you that the file
                 needs to be committed.

       R file    The file has been removed  from  your  private  copy  of  the
                 sources,  and will be removed from the source repository when
                 you run cvs commit on the file. This is  a  reminder  to  you
                 that the file needs to be committed.

       M file    The  file  is  modified  in  your  working  directory.  M can
                 indicate one of two states for  a  file  you’re  working  on:
                 either  there  were  no modifications to the same file in the
                 repository, so that your file remains as you last saw it;  or
                 there were modifications in the repository as well as in your
                 copy, but they were merged successfully, without conflict, in
                 your working directory.

       C file    A conflict was detected while trying to merge your changes to
                 file with changes from the source repository. file (the  copy
                 in  your  working directory) is now the result of merging the
                 two versions; an unmodified copy of your file is also in your
                 working  directory,  with  the  name  ‘.#file.version’, where
                 version is the revision that your modified file started from.
                 (Note  that some systems automatically purge files that begin
                 with  .# if they have not been accessed for a  few  days.  If
                 you intend to keep a copy of your original file, it is a very
                 good idea to rename it.)

       ? file    file is in your working directory, but does not correspond to
                 anything  in the source repository, and is not in the list of
                 files for cvs to  ignore  (see  the  description  of  the  -I
                 option).

            Use  the -A option to reset any sticky tags, dates, or -k options.
            (If you get a working copy of a file by using one of the  -r,  -D,
            or -k options, cvs remembers the corresponding tag, date, or kflag
            and continues using it on future updates; use  the  -A  option  to
            make  cvs  forget  these specifications, and retrieve the ’’head’’
            version of the file).

            The -jbranch option merges the changes made between the  resulting
            revision  and  the  revision that it is based on (e.g., if the tag
            refers to a branch, cvs will merge all changes made in that branch
            into your working file).

            With two -j options, cvs will merge in the changes between the two
            respective revisions. This can be used  to  ’’remove’’  a  certain
            delta  from your working file. E.g., If the file foo.c is based on
            revision 1.6 and I want to remove the changes made between 1.3 and
            1.5, I might do:

                      example% cvs update -j1.5 -j1.3 foo.c   # note the order...

            In   addition,  each  -j  option  can  contain  on  optional  date
            specification which, when used with branches, can limit the chosen
            revision  to  one  within  a  specific  date.  An optional date is
            specified by adding a colon (:) to the tag.

                      -jSymbolic_Tag:Date_Specifier

            Use the -d option to create any  directories  that  exist  in  the
            repository   if   they’re  missing  from  the  working  directory.
            (Normally, update acts only on directories  and  files  that  were
            already  enrolled  in  your working directory.) This is useful for
            updating directories that were created in the repository since the
            initial  checkout;  but  it has an unfortunate side effect. If you
            deliberately avoided certain directories in  the  repository  when
            you created your working directory (either through use of a module
            name or by listing explicitly the files and directories you wanted
            on  the  command  line),  then  updating with -d will create those
            directories, which may not be what you want.

            Use -I name to ignore  files  whose  names  match  name  (in  your
            working directory) during the update. You can specify -I more than
            once on the command line to specify several files  to  ignore.  By
            default,  update ignores files whose names match certain patterns;
            for an up to date list of ignored file names, see the cvsnt manual
            (as described in the SEE ALSO section of this manpage).

            Use -I !  to avoid ignoring any files at all.

            Use  the  -C option to overwrite locally modified files with clean
            copies  from  the  repository  (the  modified  file  is  saved  in
            ‘.#file.revision’, however).

            The  standard  cvs  command options -f, -k, -l, -P, -p, and -r are
            also available with update.

FILES

       For more detailed information on cvs supporting files, see cvs(5).

       Files in home directories:

       .cvsrc The cvs initialisation file. Lines in this file can be  used  to
              specify  default  options  for each cvs command. For example the
              line diff -c will ensure that cvs diff is always passed  the  -c
              option  in  addition  to any other options passed on the command
              line.

       .cvswrappers
              Specifies wrappers to be used in addition to those specified  in
              the CVSROOT/cvswrappers file in the repository.

       Files in working directories:

       CVS    A directory of cvs administrative files.  Do not delete.

       CVS/Entries
              List and status of files in your working directory.

       CVS/Entries.Backup
              A backup of CVS/Entries .

       CVS/Entries.Static
              Flag: do not add more entries on cvs update .

       CVS/Root
              Pathname  to  the  repository  (CVSROOT) location at the time of
              checkout. This file is used instead of the  CVSROOT  environment
              variable  if  the  environment  variable  is  not set. A warning
              message will be issued when the contents of this  file  and  the
              CVSROOT environment variable differ. The file may be over-ridden
              by  the  presence  of  the  CVS_IGNORE_REMOTE_ROOT   environment
              variable.

       CVS/Repository
              Pathname   to   the   corresponding   directory  in  the  source
              repository.

       CVS/Tag
              Contains the per-directory ’’sticky’’ tag or  date  information.
              This  file  is  created/updated when you specify -r or -D to the
              checkout or update commands, and no files are specified.

       CVS/Checkin.prog
              Name of program to run on cvs commit .

       CVS/Update.prog
              Name of program to run on B cvs update .

       Files in source repositories:

       $CVSROOT/CVSROOT
              Directory of global administrative files for repository.

       CVSROOT/commitinfo,v
              Records programs for filtering cvs commit requests.

       CVSROOT/cvswrappers,v
              Records cvs wrapper commands to be used when checking files into
              and  out of the repository. Wrappers allow the file or directory
              to be processed on the way in and out of CVS. The intended  uses
              are  many, one possible use would be to reformat a C file before
              the file is checked in, so all of the  code  in  the  repository
              looks the same.

       CVSROOT/editinfo,v
              Records  programs for editing/validating cvs commit log entries.

       CVSROOT/history
              Log file of cvs transactions.

       CVSROOT/loginfo,v
              Records programs for piping cvs commit log entries.

       CVSROOT/modules,v
              Definitions for modules in this repository.

       CVSROOT/rcsinfo,v
              Records  pathnames  to  templates  used  during  a  cvs   commit
              operation.

       CVSROOT/taginfo,v
              Records  programs  for  validating/logging  cvs tag and cvs rtag
              operations.

       MODULE/Attic
              Directory for removed source files.

       #cvs.lock
              A lock directory created by cvs when doing sensitive changes  to
              the source repository.

       #cvs.tfl.pid
              Temporary lock file for repository.

       #cvs.rfl.pid
              A read lock.

       #cvs.wfl.pid
              A write lock.

ENVIRONMENT VARIABLES

       CVSROOT
              Should  contain  the full pathname to the root of the cvs source
              repository (where the RCS files are kept). This information must
              be  available to cvs for most commands to execute; if CVSROOT is
              not set, or if you wish to override it for one  invocation,  you
              can supply it on the command line: cvs -d cvsroot cvs_command...
              You may not need to set CVSROOT if your cvs binary has the right
              path compiled in; use cvs -v to display all compiled-in paths.

       CVSREAD
              If  this  is  set, checkout and update will try hard to make the
              files in your working directory read-only. When this is not set,
              the  default  behavior is to permit modification of your working
              files.

       RCSBIN Specifies the full pathname where to find RCS programs, such  as
              co(1) and ci(1) (CVS 1.9 and older).

       CVSEDITOR
              Specifies  the  program to use for recording log messages during
              commit.  If not set, the VISUAL and EDITOR environment variables
              are tried (in that order). If neither is set, a system-dependent
              default editor (e.g., vi) is used.

       CVS_IGNORE_REMOTE_ROOT
              If this variable is set then cvs will ignore all  references  to
              remote repositories in the CVS/Root file.

       CVS_RSH
              cvs  uses the contents of this variable to determine the name of
              the remote shell command to use when starting a cvs  server.  If
              this variable is not set then rsh is used.

       CVS_SERVER
              cvs  uses the contents of this variable to determine the name of
              the cvs server command. If this variable is not set then cvs  is
              used.

       CVSWRAPPERS
              This variable is used by the cvswrappers script to determine the
              name of the wrapper file, in addition to the  wrappers  defaults
              contained in the repository (CVSROOT/cvswrappers) and the user’s
              home directory (~/.cvswrappers).

AUTHORS

       Dick Grune
              Original author of  the  cvs  shell  script  version  posted  to
              comp.sources.unix  in  the  volume6  release  of December, 1986.
              Credited with much of the cvs conflict resolution algorithms.

       Brian Berliner
              Coder and designer of the cvs program  itself  in  April,  1989,
              based on the original work done by Dick.

       Jeff Polk
              Helped Brian with the design of the cvs module and vendor branch
              support and author of the checkin(1) shell script (the  ancestor
              of cvs import ).

       Tony Hoyle
              Converted  cvs  to  Windows NT in 1999, and developed cvsnt as a
              separate project in 2002.

       And many others too numerous to mention here.

SEE ALSO

       The most comprehensive manual for CVS is Version Management with CVS by
       Per  Cederqvist et al. Depending on your system, you may be able to get
       it with the  info  cvs  command  or  it  may  be  available  as  cvs.ps
       (postscript), cvs.texinfo (texinfo source), or cvs.html.

       For  CVSNT updates, more information on documentation, software related
       to CVSNT, development of CVSNT, and more, see:
                 http://www.cvsnt.org

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