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

              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

              `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; 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, 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 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


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

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

       init   Initialize  a repository by adding the CVSROOT sub­
              directory 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  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.)

              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

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

              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

                 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

              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

              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

              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

              (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,

              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

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


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

              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

              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.

              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.

              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

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

              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

            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  the  `-C'  option  to overwrite locally modified
            files with clean copies from the repository (the mod­
            ified 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  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.

              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.

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


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


Man(1) output converted with man2html