Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 76 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here




       cvs [ cvs_options ]
              cvs_command [ command_options ] [ command_args ]


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


       CVS  is a version control system, which allows you to keep
       old versions of files (usually source code), keep a log of
       who,  when,  and  why  changes occurred, etc., like RCS or
       SCCS.  Unlike the simpler systems, CVS does not just oper­
       ate  on one file at a time or one directory at a time, but
       operates on hierarchical collections of  directories  con­
       sisting  of version controlled files.  CVS helps to manage
       releases and to control the concurrent editing  of  source
       files  among  multiple  authors.   CVS  allows triggers to
       enable/log/control various operations and works well  over
       a wide area network.

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


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

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

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


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

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

       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.


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

       Use these options to control the overall cvs program:

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

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

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

       -b bindir
              Overrides the setting of the CVSEDITOR, VISUAL, and
              EDITOR environment variables.

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

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

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

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

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

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

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

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

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


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


       Normally, when CVS starts up, it  reads  the  .cvsrc  file

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

       cvs -q

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


       Here are brief descriptions of all the cvs commands:

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

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

              Make a working directory of source files for  edit­
              ing.  (Creates or changes working directory.)

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

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

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

              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/CVS­

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

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

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

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

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

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


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

       -D date_spec
              Use  the  most  recent  revision  no   later   than
              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 cre­
              ate  a private copy of a source file; that is, when
              you use this option with  the  checkout  or  update
              commands,  cvs  associates your selected kflag with
              the file, and  continues  to  use  it  with  future
              update  commands on the same file until you specify

              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

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

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

              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


       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

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

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

              An alternate approach using `cvs update' might be:

                        example% cvs update -d new_directory

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

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

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

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

       admin [rcs-options] files...
              Requires: repository, working directory.
              Changes: repository.
              Synonym: rcs
              This  is  the cvs interface to assorted administra­
              tive facilities, similar to rcs(1).   This  command
              works  recursively, so extreme care should be used.
              source  directories and files, or paths to directo­
              ries or files in the repository.

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

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

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

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

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

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

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

              With  two -j options, cvs will merge in the changes
              between the two respective revisions.  This can  be
              Use the -N option with `-d dir' to avoid shortening
              module paths in  your  working  directory.    (Nor­
              mally,  cvs shortens paths as much as possible when
              you specify an explicit target directory.)

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

              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]
              Requires: working directory, repository.
              Changes: repository.
              Synonym: ci
              Use `cvs  commit'  when  you  want  to  incorporate
              changes  from  your  working  source files into the
              general source repository.

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

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

              When all is well, an editor is invoked to allow you
              to  enter a log message that will be written to one

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

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

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

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

              Others  would simply do `cvs checkout -rEXPR1 what­
              ever_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'  com­
              mand.   If you don't specify a particular revision,
              your files are compared  with  the  revisions  they
              were  based  on.  You can also use the standard cvs
              command option -r to specify a particular  revision
              sponding  revision  in  the source repository (i.e.
              files that you have changed), or that  differ  from
              the revision specified.

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

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

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

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

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

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

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

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

             -o  Report on checked-out modules.
                 tory;  `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 modi­
                 fied; `A', when a file is first added; and  `R',
                 when a file is removed.

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

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

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

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

             -l  Show last modification only.

             -w  Show only the  records  for  modifications  done
                 from  the same working directory where `cvs his­
                 tory' 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.

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

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

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

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

              The  outside  source  is  saved  in  a  first-level
              branch, by default `1.1.1'.  Updates are leaves  of
              this  branch;  for  example,  files  from the first
              imported collection  of  source  will  be  revision
              `',  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 cre­
              ated each time you execute `cvs import'.

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

              There are three additional special options.

              Use `-d' to specify that each file's time  of  last
              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]] mod­
              Requires: repository.
              Changes: nothing.
              Synonym: patch
              Builds  a  Larry  Wall format patch(1) file between
              two releases, that can be  fed  directly  into  the
              patch  program  to  bring an old release up-to-date
              with the new release.  (This is one of the few  cvs
              commands  that  operates  directly from the reposi­
              tory, and doesn't require a prior  checkout.)   The
              diff  output is sent to the standard output device.
              You can specify  (using  the  standard  -r  and  -D
              options) any combination of one or two revisions or
              dates.  If only one revision or date is  specified,
              the  patch  file  reflects differences between that
              revision or date and the current ``head'' revisions
              in the RCS file.

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

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

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

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

              tory,  if you like; but you risk losing changes you
              may have forgotten, and you leave no trace  in  the
              cvs  history file that you've abandoned your check­

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

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

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

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

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

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

       rtag  [-falnRQq] [-b] [-d] [-r tag | -D date] symbolic_tag
              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
              exists on that file to the new repository versions.
              Without the -F option, attempting to use `cvs rtag'
              to apply a tag that already  exists  on  that  file
              will produce an error message.

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

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

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

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

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

       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
              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 direc­
              tory.  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 files.

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

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

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

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

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

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

              `cvs  tag' will not move a tag that already exists.
              dard -l option, or specify the recursion explicitly
              by using -R.

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

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

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

       P file    Like U, but the CVS server sends a patch instead
                 of an entire file.  This accomplishes  the  same
                 thing as U using less bandwidth.

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

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

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

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

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

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

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

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

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


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

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


       For more detailed information on cvs supporting files, see

       Files in home directories:

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

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

       Files in working directories:

       CVS    A directory of cvs administrative  files.   Do  not

              List and status of files in your working directory.

              A backup of `CVS/Entries'.

              Flag: do not add more entries on `cvs update'.

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

              Pathname  to  the  corresponding  directory  in the
              source repository.

              Directory of global administrative files for repos­

              Records  programs  for   filtering   `cvs   commit'

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

              Records  programs  for editing/validating `cvs com­
              mit' log entries.

              Log file of cvs transactions.

              Records  programs  for  piping  `cvs  commit'   log

              Definitions for modules in this repository.

              Records  pathnames  to templates used during a `cvs
              commit' operation.

              Records programs for validating/logging  `cvs  tag'
              and `cvs rtag' operations.

              Directory for removed source files.

              A  lock  directory created by cvs when doing sensi­
              tive changes to the source repository.

              Temporary lock file for repository.

              A read lock.


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

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

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

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

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

              cvs uses the contents of this variable to determine
              the name of the cvs server command.  If this  vari­
              able is not set then `cvs' is used.

              This  variable  is used by the `cvswrappers' script
              to determine the name of the wrapper file, in addi­
              tion  to  the  wrappers  defaults  contained in the
              repository  (CVSROOT/cvswrappers)  and  the  user's
              home directory (~/.cvswrappers).


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

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

       For CVS updates, more information on documentation,  soft­
       ware related to CVS, development of CVS, and more, see:

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




Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
The Linux Tutorial welcomes your suggestions and ideas.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.24 Seconds