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

  man pages->FreeBSD 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 it may no
       longer be kept up-to-date.  For more current  and  in-depth  documentation,
 please consult the Cederqvist manual (via the info cvs command or
       otherwise, 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 created.

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

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

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

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

OPTIONS    [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  command_options  and  command_arguments  to
       fully specify what the cvs_command will do.

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

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

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

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

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

       -R     Turns  on  read-only  repository mode.  This allows one to check
              out from a read-only  repository,  such  as  within  an  anoncvs
              server,  or from a CDROM repository.  Same effect as if the CVSREADONLYFS
 environment variable is set.  Using -R can also  considerably
 speed up checkout's over NFS.

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

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

       -g     Forces group-write perms on working files.  This option is typically
 used when you have multiple users sharing a single checked
              out source tree, allowing them to operate their  shells  with  a
              less  dangerous  umask.  To use this feature, create a directory
              to hold the checked-out source tree, set it to a private  group,
              and  set  up  the  directory  such  that  files created under it
              inherit the group id of the directory.   This  occurs  automatically
  with  FreeBSD.  With SysV you must typically set the SGID
              bit on the directory.  The users who are to  share  the  checked
              out tree must be placed in that group.  Note that the sharing of
              a single checked-out source tree is very different  from  giving
              several  users  access  to a common CVS repository.  Access to a
              common CVS repository already maintains shared group-write perms
              and does not require this option.

              To  use the option transparently, simply place the line 'cvs -g'
              in your ~/.cvsrc file.  Doing this is not recommended unless you
              firewall  all  your  source  checkouts within a private group or
              within a private mode 0700 directory.

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

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

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

       Global  options  are specified using the cvs keyword.  For example, the

       cvs -q

       will mean that all `cvs' commands will behave as thought he  -q  global
       option had been supplied.

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

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

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

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

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

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

              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/his-
              tory' 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

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

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

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


       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 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, sta-
              tus,  tag,  and  update.   Warning:  this is not the same as the
              overall `cvs -l' option, which you can specify to the left of  a
              cvs command!

       -n     Do  not  run any checkout/commit/tag/update program.  (A program
              can be specified to run on each of these activities, in the modules
  database;  this  option  bypasses it.)  Available with the
              checkout, commit, export, and rtag commands.  Warning:  this  is
              not the same as the overall `cvs -n' option, which you can specify
 to the left of a cvs command!

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

       -T     Create/Update CVS/Template by copying it from the (local) repository.
  This option is useful for developers maintaining a local
              cvs  repository  but commiting to a remote repository.  By maintaining
 CVS/Template the remote commits will still  be  able  to
              bring  up  the  proper  template  in  the commit editor session.
              Available with the checkout and update commands.

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

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

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

CVS COMMANDS    [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 things:

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

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

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

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

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

              An alternate approach using `cvs update' might be:

                        example% cvs update -d new_directory

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

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

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

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

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

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

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

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

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

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

                        example% cvs checkout -jTAG:yesterday -jTAG module

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

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

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

              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 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  commands.   Then,
              either  checkout  or  update can be used to base your sources on
              the newly created  branch.   From  that  point  on,  all  commit
              changes  made within these working sources will be automatically
              added to a branch revision,  thereby  not  perturbing  main-line
              development  in  any  way.   For example, if you had to create a
              patch to the 1.2 version of the product,  even  though  the  2.0
              version is already under development, you might do:

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

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

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

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

       diff [-kl] [rcsdiff_options] [[-r rev1 | -D date1 | -j rev1:date1]  [-r
       rev2 | -D date2 | -j rev2: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 (on the head branch) in
              the past, and you can also specify -j options to diff against  a
              revision  relative  to  a branch tag in the past.  The -r and -D
              and -j options can be mixed together with at  most  two  options
              ever specified.

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

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

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

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

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

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

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

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

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

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

             -o  Report on checked-out modules.

             -T  Report on all tags.

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

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

             -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

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

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

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

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

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

              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 check-
              out'.  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] symbolic_tag modules...
              Requires: repository.
              Changes: repository.
              Synonym: rfreeze
              You  can use this command to assign symbolic tags to particular,
              explicitly specified source versions in  the  repository.   `cvs
              rtag' works directly on the repository contents (and requires no
              prior checkout).  Use `cvs tag' instead, to base  the  selection
              of versions to tag on the contents of your working directory.

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

              `cvs rtag' will not move a tag that already exists.  With the -F
              option,  however, `cvs rtag' will re-locate any instance of sym-
              bolic_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] symbolic_tag
              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 potentially surprising aspect of the fact that cvs tag operates
 on the repository is that you are  tagging  the  checked-in
              revisions,  which may differ from locally modified files in your
              working directory.  If you want to avoid doing this by  mistake,
              specify the -c option to cvs tag.  If there are any locally modified
 files, CVS will abort with an error  before  it  tags  any

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

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

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

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

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

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

              `cvs  tag' will not move a tag that already exists.  With the -F
              option, however, `cvs tag' will re-locate any instance  of  sym-

 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