*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->OpenBSD man pages -> cvs (1)              



NAME    [Toc]    [Back]

       cvs - Concurrent Versions System

SYNOPSIS    [Toc]    [Back]

       cvs [ cvs_options ]
              cvs_command [ command_options ] [ command_args ]

NOTE    [Toc]    [Back]

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

DESCRIPTION    [Toc]    [Back]

       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 operate
 on one file at a time or one directory at a time,  but
       operates  on  hierarchical collections of directories consisting
 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.


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

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

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

       cvs add file...
              Use this command to enroll new files in cvs records
              of your working directory.  The files will be added
              to the  repository  the  next  time  you  run  `cvs
              commit'.   Note:  You  should  use the `cvs import'
              command to bootstrap new sources  into  the  source
              repository.   `cvs  add' is only used for new files
              to an already checked-out module.

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

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

OPTIONS    [Toc]    [Back]

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

       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    [Toc]    [Back]

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

       Use these options to control the overall cvs program:

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

       -R     Allows cvs to run properly without write access  to
              its  log  file. See also the CVSREADONLYFS environment

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

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

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

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

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

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

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

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

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

       -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
              compression level compression-level to compress and
              de-compress data as it is transferred.

USAGE    [Toc]    [Back]

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

CVS STARTUP FILE    [Toc]    [Back]

       Normally,  when  CVS  starts  up, it reads the .cvsrc file
       from the home directory of  the  user  reading  it.   This
       startup procedure can be turned off with the -f flag.

       The  .cvsrc  file  lists CVS commands with a list of arguments,
 one command per line.  For example,  the  following
       line in .cvsrc:

       diff -c

       will  mean  that  the  `cvs  diff'  command will always be
       passed the -c option in addition to any other options that
       are  specified  in  the command line (in this case it will
       have the effect of producing context sensitive  diffs  for
       all executions of `cvs diff' ).

CVS COMMAND SUMMARY    [Toc]    [Back]

       Here are brief descriptions of all the cvs commands:

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

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

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

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

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

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

              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 subdirectory
 and some default control files. You  must
              use  this  command  or initialize the repository in
              some other way before you can use it.

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

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

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

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

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

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

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

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


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

       -D date_spec
              Use   the   most  recent  revision  no  later  than
              date_spec  (a  single  argument,  date  description
              specifying  a date in the past).  A wide variety of
              date  formats  are  supported,  in  particular  ISO
              ("1972-09-24  20:05")  or  Internet  ("24  Sep 1972
              20:05").  The date_spec is interpreted as being  in
              the  local  timezone, unless a specific timezone is
              specified.  The specification  is  ``sticky''  when
              you use it to make a private copy of a source file;
              that is, when you get a working file using -D,  cvs
              records  the  date  you  specified, so that further
              updates in the same directory  will  use  the  same
              date  (unless  you  explicitly override it; see the
              description of the update command).  -D  is  available
  with  the  checkout,  diff,  history, export,
              rdiff, rtag,  and  update  commands.   Examples  of
              valid date specifications include:
                        1 month ago
                        2 hours ago
                        400000 seconds ago
                        last year
                        last Monday
                        a fortnight ago
                        3/31/92 10:00:07 PST
                        January 23, 1987 10:05pm
                        22:00 GMT

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

       -k kflag
              Alter the default processing of keywords.   The  -k
              option  is  available with the add, checkout, diff,
              export, rdiff, and  update  commands.   Your  kflag
              specification is ``sticky'' when you use it to create
 a private copy of a source file; that is,  when
              you  use  this  option  with the checkout or update
              commands, cvs associates your selected  kflag  with
              the  file,  and  continues  to  use  it with future
              update commands on the same file until you  specify

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

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

       -r tag Use the revision  specified  by  the  tag  argument
              instead  of the default ``head'' revision.  As well
              as arbitrary tags defined with the tag or rtag command,
 two special tags are always available: `HEAD'
              refers to the most recent version available in  the
              repository,  and  `BASE' refers to the revision you
              last checked out into the  current  working  directory.

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

       -t id  Expand the RCS identifier specified by the id argument
  in addition to the default ``Id'' identifier.
              -t is available  with  the  checkout,  export,  and
              update  commands.  If the identifier name is specified
 as ``-'', no additional  identifiers  will  be

CVS COMMANDS    [Toc]    [Back]

       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

           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.

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

       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 directory
 in the source repository.  The files or directories
 specified with add must already exist in the
              current directory (which  must  have  been  created
              with  the  checkout  command).   To add a whole new
              directory hierarchy to the source  repository  (for
              example, files received from a third-party vendor),
              use the `cvs import' command instead.

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

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

              An alternate approach using `cvs update' might be:

                        example% cvs update -d new_directory

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

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

              You will have the opportunity to specify a  logging
              message,  as  usual,  when  you use `cvs commit' to
              make the new file permanent.  If you'd like to have
              another  logging  message associated with just 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 useful
 for checking in binaries  that  shouldn't  have
              keywords expanded.

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

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

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

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

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

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

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

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

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

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

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

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

                        example%  cvs  checkout   -jTAG:yesterday
-jTAG module

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

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

              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 current
 directory only.  Sometimes  you  may  want  to
              force  a  file  to  be  committed even though it is
              unchanged; this is achieved with the -f flag, which
              also has the effect of disabling recursion (you can
              turn it back on with -R of course).

              commit verifies that the selected files are  up  to
              date  with  the  current  revisions  in  the source
              repository; it will notify you,  and  exit  without
              committing,  if  any of the specified files must be
              made current first with `cvs update'.  commit  does
              not  call  the  update  command for you, but rather
              leaves that for you to do when the time is right.
              When all is well, an editor is invoked to allow you
              to  enter a log message that will be written to one
              or more logging programs and placed in  the  source
              repository  file.   You can instead specify the log
              message on the command line  with  the  -m  option,
              thus  suppressing the editor invocation, or use the
              -F option to specify that the  argument  file  contains
 the log message.

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

                        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 commands.
  Then, either checkout or update can be used
              to base your sources on the newly  created  branch.
              From  that point on, all commit changes made within
              these working sources will be  automatically  added
              to  a branch revision, thereby not perturbing mainline
 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    [Toc]    [Back]

                        example%  cvs   checkout   -rFCS1_2_Patch
                        example% cd product_module
                        [[ hack away ]]
                        example% cvs commit

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

                        example% cvs tag -b EXPR1
                        example% cvs update -rEXPR1
                        [[ hack away ]]
                        example% cvs commit
              Others   would  simply  do  `cvs  checkout  -rEXPR1
              whatever_module' to work with you on the experimental

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

              See  rcsdiff(1)  for  a  list  of  other   accepted

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

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

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

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

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

              Warning: `cvs history' uses `-f', `-l',  `-n',  and
              `-p' in ways that conflict with the descriptions in

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

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

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

             -o  Report on checked-out modules.

             -T  Report on all tags.

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

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

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

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

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

             -l  Show last modification only.

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

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

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

             -D date
                 Show data since date.

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

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

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

             -u name
                 Show records for user name.

       import [-options] repository vendortag releasetag...
              Requires: Repository,  source  distribution  directory.

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

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

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

              By default, certain file names are  ignored  during
              `cvs import': names associated with CVS administration,
 or with other common source control  systems;
              common names for patch files, object files, archive
              files, and editor backup  files;  and  other  names
              that  are  usually artifacts of assorted utilities.
              For an up to date list of ignored file  names,  see
              the 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
              `',  then  files  from  the  first  imported
              update will be revision `', and so on.

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

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

              There are three additional special options.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       remove [-lR] [files...]
              Requires: Working directory.
              Changes: Working directory.
              Synonyms: rm, delete
              Use this command to declare that you wish to remove
              files  from  the  source repository.  Like most cvs
              commands, `cvs remove' works on files in your working
  directory, not directly on the repository.  As
              a safeguard, it also requires that you first  erase
              the specified files from your working directory.
              The  files are not actually removed until you apply
              your changes to the repository with commit; at that
              point,  the  corresponding  RCS files in the source
              repository are moved  into  the  `Attic'  directory
              (also within the source repository).

              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

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

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

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

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

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

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

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

       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

              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 creating
 a software distribution.  The checkout,  export
              and  update  commands allow you to extract an exact
              copy of a tagged release at any time in the future,
              regardless  of  whether  files  have  been changed,
              added, or removed since the release was tagged.

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

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

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

              If  you  use `cvs tag -d symbolic_tag...', the symbolic
 tag you specify is deleted instead  of  being
              added.   Warning:  Be  very  certain of your ground
              before you delete a  tag;  doing  this  effectively
              discards  some  historical  information,  which may
              later turn out to have been valuable.

              `cvs tag' will not move a tag that already  exists.
              With  the  -F  option,  however, `cvs tag' will relocate
 any instance of  symbolic_tag  that  already
              exists on that file to the new repository versions.
              Without the -F option, attempting to use `cvs
 Similar pages
Name OS Title
cvsconfig Linux The GNU Concurrent Versions System
cvs-pserver Linux The GNU Concurrent Versions System
cvs Linux Concurrent Versions System support files
cvs NetBSD Concurrent Versions System support files
cvs OpenBSD Concurrent Versions System support files
cvs FreeBSD Concurrent Versions System support files
use_sys_check Tru64 Utilities for generating system configuration information and analysis [Versions 124 through 126]
sys_check Tru64 Utilities for generating system configuration information and analysis [Versions 124 through 126]
runsyscheck Tru64 Utilities for generating system configuration information and analysis [Versions 124 through 126]
sccsdiff Tru64 Compares two versions of a Source Code Control System (SCCS) file
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service