CVS(1)                                                     CVS(1)

NAME
       cvs - Concurrent Versions System

SYNOPSIS
       cvs [ cvs_options ]
              cvs_command [ command_options ] [ command_args ]

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

DESCRIPTION
       CVS is a version control system, which allows you to  keep
       old versions of files (usually source code), keep a log of
       who, when, and why changes occurred,  etc.,  like  RCS  or
       SCCS.  Unlike the simpler systems, CVS does not just oper-
       ate on one file at a time or one directory at a time,  but
       operates  on  hierarchical collections of directories con-
       sisting of version controlled files.  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 mas-
       ter 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 rel-
              ative 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 reposi-
              tory.

       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 com-
       mand_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 com-
       mand).

       There are only two situations where you may omit  cvs_com-
       mand: `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
       As  of release 1.6, cvs supports GNU style long options as
       well as short options.  Only a few long options  are  cur-
       rently  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 com-
              mand).  If you don't specify a command  name,  `cvs
              -H'  displays  a summary of all the commands avail-
              able.

       -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; informa-
              tional  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  path-
              name  of  the  master source repository.  Overrides
              the setting of the  CVSROOT  environment  variable.
              This value should be specified as an absolute path-
              name.

       -e editor
              Use  editor  to  enter  revision  log  information.
              Overrides the setting of the CVSEDITOR and the EDI-
              TOR 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 his-
              tory.

       -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 unfa-
              miliar 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  com-
              press  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.  How-
       ever,  many options are available across several commands.
       You can display a usage summary for each command by speci-
       fying 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 argu-
       ments, 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  direc-
              tory without changing it.)

       checkout
              Make  a working directory of source files for edit-
              ing.  (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 reposi-
              tory or working directory.)

       export Prepare  copies  of a set of source files for ship-
              ment 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 sym-
              bolic 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 cvs(5).

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

       log    Display  log information.  (Does not change reposi-
              tory 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 reposi-
              tory.)

       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, ver-
              sion in working directory, whether working  version
              has  been  edited and, optionally, symbolic tags in
              the RCS file.  (Does not change repository or work-
              ing directory.)

       tag    Specify a symbolic tag for files in the repository.
              By default, tags the revisions that were last  syn-
              chronized  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 avail-
       able  across  several cvs commands.  Not all commands sup-
       port all of these options; each option is  only  supported
       for  commands  where it makes sense.  However, when a com-
       mand has one of these options you can count  on  the  same
       meaning  for the option as in other commands.  (Other com-
       mand options, which are listed with  the  individual  com-
       mands, 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 avail-
              able 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.

       -H     Help;  describe the options available for this com-
              mand.  This is the only option  supported  for  all
              cvs commands.

       -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 cre-
              ate  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 com-
              mand, 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 direc-
              tory.

              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] [-m 'message'] files...
              Requires: repository, working directory.
              Changes: working directory.
              Synonym: new
              Use  the add command to create a new file or direc-
              tory in the source repository.  The files or direc-
              tories 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 cor-
              rect place in the source repository, and the neces-
              sary  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 work-
              ing directory, it's probably simpler  to  use  `cvs
              checkout' or `cvs update -d'.)

              The added files are not placed in the source repos-
              itory 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  resur-
              rect  the  file,  if no `cvs commit' command inter-
              vened.

              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 cre-
              ation 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 use-
              ful 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 administra-
              tive 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 exe-
              cute `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  cvs(5))  for  some  collection  of
              source  directories and files, or paths to directo-
              ries 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 reposi-
              tory;  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  usu-
              ally has the same name as the specified module.  In
              the case of a module alias, the created  sub-direc-
              tory 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  permit-
              ted,  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 work-
              ing 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  spe-
              cific  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.    (Nor-
              mally,  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 mod-
              ifying 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]  [-m  'log_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 cur-
              rent 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  con-
              tains 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

              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 com-
              mands.  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 experi-
              mental 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 uti-
              lize 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 experimen-
              tal 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'  com-
              mand.   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  revi-
              sions  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 corre-
              sponding  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 with-
              out the cvs administrative directories.  For  exam-
              ple,  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 mean-
              ings 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  mean-
                 ingfully  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  combi-
                 nation.   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  suc-
                 ceeded;  and 'C', when a merge was necessary but
                 collisions were detected (requiring manual merg-
                 ing).    Finally,  one  of  three  record  types
                 results from commit: `M', when a file was  modi-
                 fied;  `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 min-
                 utes 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  direc-
              tory.
              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 administra-
              tion, 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 Cederqvist 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 cre-
              ated each time you execute `cvs import'.

              One of the standard cvs command options  is  avail-
              able:  -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 reposi-
              tory, 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 con-
              tained 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  pro-
              duced.   Instead, a summary of the changed or added
              files between the two releases is sent to the stan-
              dard  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  direc-
              tory,  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 check-
              out.

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

              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] sym-
              bolic_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  check-
              out).  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 soft-
              ware distributions) should not be removed, but  the
              -d  option  is  available as a means to remove com-
              pletely 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  argu-
              ment.   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 exe-
              cute 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] sym-
              bolic_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 creat-
              ing 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 sym-
              bolic 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 subdi-
              rectories; you can prevent this by using the  stan-
              dard -l option, or specify the recursion explicitly
              by using -R.

       update [-AdflPpQqR] [-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 rec-
              oncile your work with any revisions applied to  the
              source  repository  since  your  last  checkout  or
              update.

              update keeps you informed of its progress by print-
              ing  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  modifi-
                 cations  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  suc-
                 cessfully,  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 work-
                 ing  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  spe-
            cific  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 directo-
            ries 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
            Cederqvist  manual (as described in the SEE ALSO sec-
            tion of this manpage).

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

            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 CVS-
              ROOT 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 com-
              mands, 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 `cvs update'.

       Files in source repositories:

       $CVSROOT/CVSROOT
              Directory of global administrative files for repos-
              itory.

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

       CVSROOT/cvswrappers,v
              Records cvs wrapper commands to be used when check-
              ing 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  sensi-
              tive 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 invoca-
              tion, 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  com-
              piled  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 pro-
              grams, such as co(1) and ci(1) (CVS 1.9 and older).

       CVSEDITOR
              Specifies the program to use for recording log mes-
              sages during commit.  If not set, the EDITOR  envi-
              ronment variable is used instead.  If EDITOR is not
              set either, the default is /usr/ucb/vi.

       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  vari-
              able 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 addi-
              tion  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').

       And many others too numerous to mention here.

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

       For CVS updates, more information on documentation,  soft-
       ware related to CVS, development of CVS, and more, see:
                 http://www.cyclic.com
                 http://www.loria.fr/~molli/cvs-index.html

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

                                                                1