Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
CVS(1)							   CVS(1)

NAME
       cvs - Concurrent Versions System

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

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

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

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

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

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

       cvs update
	      Execute  this  command  from  within  your  private
	      source  directory  when  you  wish  to  update your
	      copies of source	files  from  changes  that  other

								1

CVS(1)							   CVS(1)

	      developers  have	made to the source in the reposi­
	      tory.

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

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

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

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

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

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

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

       Use these options to control the overall cvs program:

       -H [ --help ]
	      Display  usage  information  about  the	specified
	      cvs_command   (but  do  not  actually  execute  the

								2

CVS(1)							   CVS(1)

	      command).  If you don't  specify	a  command  name,
	      `cvs  -H'  displays  a  summary of all the commands
	      available.

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

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

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

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

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

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

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

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

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

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

       -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 repos­
	      itory.   Same  effect as if the CVSREADONLYFS envi­
	      ronment  variable  is  set.   Using  -R  can   also

								3

CVS(1)							   CVS(1)

	      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 sev­
	      eral 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  pri­
	      vate 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 connection.

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

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

								4

CVS(1)							   CVS(1)

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

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

       diff -c

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

       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.

CVS COMMAND SUMMARY
       Here are brief descriptions of all the cvs commands:

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

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

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

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

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

       export Prepare  copies  of  a  set  of  source  files  for

								5

CVS(1)							   CVS(1)

	      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 sym­
	      bolic tag must  be  specified.   (Does  not  change
	      repository;  creates  directory  similar to working
	      directories).

       history
	      Show reports on cvs commands  that  you  or  others
	      have  executed on a particular file or directory in
	      the source repository.  (Does not change repository
	      or  working directory.)  History logs are kept only
	      if     enabled	 by	creation      of      the
	      `$CVSROOT/CVSROOT/history' file; see cvs(5).

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

       init   Initialize  a repository by adding the CVSROOT sub­
	      directory and some default control files. You  must
	      use  this  command  or initialize the repository in
	      some other way before you can use it.

       log    Display log information.	(Does not change  reposi­
	      tory or working directory.)

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

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

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

       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

								6

CVS(1)							   CVS(1)

	      synchronized   with   your    working    directory.
	      (Changes	repository  directly; uses working direc­
	      tory without changing it.)

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

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

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

       -f     When  you  specify  a particular date or tag to cvs

								7

CVS(1)							   CVS(1)

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

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

	      Some of the more useful kflags are -ko and -kb (for
	      binary files), and  -kv  which  is  useful  for  an
	      export where you wish to retain keyword information
	      after an import at some other site.

       -l     Local;  run  only  in  current  working  directory,
	      rather   than   recurring  through  subdirectories.
	      Available with the  following  commands:	checkout,
	      commit,  diff, export, remove, rdiff, rtag, status,
	      tag, and update.	Warning: this is not the same  as
	      the  overall `cvs -l' option, which you can specify
	      to the left of a cvs command!

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

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

       -p     Pipe  the  files	retrieved  from the repository to
	      standard output, rather than writing  them  in  the

								8

CVS(1)							   CVS(1)

	      current directory.  Available with the checkout and
	      update commands.

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

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

CVS COMMANDS
       Here (finally) are details on all the cvs commands and the
       options	each  accepts.	 The  summary lines at the top of
       each  command's	description  highlight	three  kinds   of
       things:

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

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

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

       add [-k kflag] [-m 'message'] files...
	      Requires: repository, working directory.
	      Changes: working directory.
	      Synonym: new

								9

CVS(1)							   CVS(1)

	      Use the add command to create a new file or  direc­
	      tory in the source repository.  The files or direc­
	      tories specified with add must already exist in the
	      current  directory  (which  must	have been created
	      with the checkout command).  To  add  a  whole  new
	      directory  hierarchy  to the source repository (for
	      example, files received from a third-party vendor),
	      use the `cvs import' command instead.

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

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

	      An alternate approach using `cvs update' might be:

			example% cvs update -d new_directory

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

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

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

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

							       10

CVS(1)							   CVS(1)

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

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

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

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

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

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

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

							       11

CVS(1)							   CVS(1)

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

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

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

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

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

			example% cvs checkout -jTAG:yesterday -jTAG module

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

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

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

	      Use  the	-s  option  to	display per-module status
	      information stored with the -s  option  within  the
	      modules file.

       commit	[-lnR]	[-m  'log_message'  |  -f  file]  [-r
       revision] [files...]

							       12

CVS(1)							   CVS(1)

	      Requires: working directory, repository.
	      Changes: repository.
	      Synonym: ci
	      Use  `cvs  commit'  when	you  want  to incorporate
	      changes from your working  source  files	into  the
	      general source repository.

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

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

	      When all is well, an editor is invoked to allow you
	      to enter a log message that will be written to  one
	      or  more	logging programs and placed in the source
	      repository file.	You can instead specify  the  log
	      message  on  the	command  line with the -m option,
	      thus suppressing the editor invocation, or use  the
	      -F  option  to  specify that the argument file con­
	      tains the log message.

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

			example% cvs commit -r3.0

	      cvs will only allow you to  commit  to  a  revision
	      that is on the main trunk (a revision with a single
	      dot).  However, you can also  commit  to	a  branch
	      revision (one that has an even number of dots) with
	      the -r option.  To create a  branch  revision,  one
	      typically use the -b option of the rtag or tag com­
	      mands.  Then, either checkout or update can be used
	      to  base	your sources on the newly created branch.

							       13

CVS(1)							   CVS(1)

	      From that point on, all commit changes made  within
	      these  working  sources will be automatically added
	      to a branch revision, thereby not perturbing  main-
	      line  development  in any way.  For example, if you
	      had to create a patch to the  1.2  version  of  the
	      product,	even  though  the  2.0 version is already
	      under development, you might do:

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

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

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

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

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

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

	      If you don't specify any files, diff  will  display

							       14

CVS(1)							   CVS(1)

	      differences  for	all  those  files  in the current
	      directory (and its subdirectories, unless  you  use
	      the standard option -l) that differ from the corre­
	      sponding revision in the	source	repository  (i.e.
	      files  that  you have changed), or that differ from
	      the revision specified.

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

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

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

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

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

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

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

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

							       15

CVS(1)							   CVS(1)

	     -o  Report on checked-out modules.

	     -T  Report on all tags.

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

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

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

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

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

	     -l  Show last modification only.

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

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

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

							       16

CVS(1)							   CVS(1)

	     -D date
		 Show data since date.

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

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

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

	     -u name
		 Show records for user name.

       import [-options] repository vendortag releasetag...
	      Requires:  Repository,  source  distribution direc­
	      tory.
	      Changes: repository.
	      Use `cvs import' to incorporate  an  entire  source
	      distribution from an outside source (e.g., a source
	      vendor) into your source repository directory.  You
	      can use this command both for initial creation of a
	      repository, and for wholesale updates to the module
	      form the outside source.

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

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

	      By  default,  certain file names are ignored during
	      `cvs import': names associated with CVS administra­
	      tion,  or with other common source control systems;
	      common names for patch files, object files, archive
	      files,  and  editor  backup  files; and other names
	      that are usually artifacts of  assorted  utilities.
	      For  an  up to date list of ignored file names, see

							       17

CVS(1)							   CVS(1)

	      the Cederqvist manual (as described in the SEE ALSO
	      section of this manpage).

	      The  outside  source  is	saved  in  a  first-level
	      branch, by default `1.1.1'.  Updates are leaves  of
	      this  branch;  for  example,  files  from the first
	      imported collection  of  source  will  be  revision
	      `1.1.1.1',  then	files  from  the  first  imported
	      update will be revision `1.1.1.2', and so on.

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

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

	      There are three additional special options.

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

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

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

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

       rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]]
       modules...
	      Requires: repository.
	      Changes: nothing.
	      Synonym: patch

							       18

CVS(1)							   CVS(1)

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

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

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

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

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

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

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

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

							       19

CVS(1)							   CVS(1)

	      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 work­
	      ing copies of the source files be  deleted  if  the
	      release succeeds.

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

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

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

       rtag [-falnRQq]	[-b]  [-d]  [-r  tag  |  -D  date]  sym­
       bolic_tag modules...
	      Requires: repository.
	      Changes: repository.
	      Synonym: rfreeze
	      You can use this command to assign symbolic tags to
	      particular, explicitly specified source versions in
	      the repository.  `cvs rtag' works directly  on  the
	      repository  contents  (and requires no prior check­
	      out).  Use `cvs tag' instead, to base the selection
	      of  versions to tag on the contents of your working
	      directory.

							       20

CVS(1)							   CVS(1)

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

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

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

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

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

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

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

       status [-lRqQ] [-v] [files...]
	      Requires: working directory, repository.
	      Changes: nothing.
	      Display  a  brief  report  on the current status of
	      files  with  respect  to	the  source   repository,
	      including   any	``sticky''  tags,  dates,  or  -k
	      options.	(``Sticky''  options  will  restrict  how
	      `cvs update' operates until you reset them; see the
	      description of `cvs update -A...'.)

							       21

CVS(1)							   CVS(1)

	      You can also use this  command  to  anticipate  the
	      potential  impact of a `cvs update' on your working
	      source directory.  If you do not specify any  files
	      explicitly,  reports  are  shown for all files that
	      cvs has placed in your working directory.  You  can
	      limit  the  scope  of  this  search  to the current
	      directory itself (not its subdirectories) with  the
	      standard	-l  option  flag;  or  you can explicitly
	      request  recursive  status  reports  with  the   -R
	      option.

	      The  -v option causes the symbolic tags for the RCS
	      file to be displayed as well.

       tag [-lQqR] [-F] [-b] [-d] [-r tag | -D date]  [-f]  sym­
       bolic_tag [files...]
	      Requires: working directory, repository.
	      Changes: repository.
	      Synonym: freeze
	      Use this command to assign  symbolic  tags  to  the
	      nearest	repository   versions	to  your  working
	      sources.	The tags are applied immediately  to  the
	      repository, as with rtag.

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

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

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

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

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

							       22

CVS(1)							   CVS(1)

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

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

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

	      Normally, tag executes recursively  through  subdi­
	      rectories;  you can prevent this by using the stan­
	      dard -l option, or specify the recursion explicitly
	      by using -R.

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

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

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

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

							       23

CVS(1)							   CVS(1)

		 needs to be committed.

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

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

       C file	 A  conflict  was  detected while trying to merge
		 your changes  to  file  with  changes	from  the
		 source repository.  file (the copy in your work­
		 ing directory) is now the result of merging  the
		 two versions; an unmodified copy of your file is
		 also in your working directory,  with	the  name
		 `.#file.version',  where version is the revision
		 that your modified  file  started  from.   (Note
		 that some systems automatically purge files that
		 begin with  `.#' if they have not been  accessed
		 for a few days.  If you intend to keep a copy of
		 your original file, it is a very  good  idea  to
		 rename it.)

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

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

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

	    With two -j options, cvs will merge  in  the  changes
	    between  the  two  respective revisions.  This can be

							       24

CVS(1)							   CVS(1)

	    used to ``remove'' a certain delta from your  working
	    file.   E.g.,  If the file foo.c is based on revision
	    1.6 and I want to remove the changes made between 1.3
	    and 1.5, I might do:

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

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

		      -jSymbolic_Tag:Date_Specifier

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

	    Use -I name to ignore files whose  names  match  name
	    (in  your  working directory) during the update.  You
	    can specify -I more than once on the command line  to
	    specify  several files to ignore.  By default, update
	    ignores files whose names match certain patterns; for
	    an	up  to	date  list of ignored file names, see the
	    Cederqvist manual (as described in the SEE ALSO  sec­
	    tion of this manpage).

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

	    Use  the  `-C'  option  to overwrite locally modified
	    files with clean copies from the repository (the mod­
	    ified file is saved in `.#file.revision', however).

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

FILES
       For more detailed information on cvs supporting files, see
       cvs(5).

       Files in home directories:

							       25

CVS(1)							   CVS(1)

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

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

       Files in working directories:

       CVS    A directory of cvs administrative  files.   Do  not
	      delete.

       CVS/Entries
	      List and status of files in your working directory.

       CVS/Entries.Backup
	      A backup of `CVS/Entries'.

       CVS/Entries.Static
	      Flag: do not add more entries on `cvs update'.

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

       CVS/Repository
	      Pathname	to  the  corresponding	directory  in the
	      source repository.

       CVS/Tag
	      Contains the per-directory ``sticky'' tag  or  date
	      information.  This file is created/updated when you
	      specify -r or -D to the  checkout  or  update  com­
	      mands, and no files are specified.

       CVS/Checkin.prog
	      Name of program to run on `cvs commit'.

       CVS/Update.prog
	      Name of program to run on `cvs update'.

       Files in source repositories:

							       26

CVS(1)							   CVS(1)

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

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

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

       CVSROOT/editinfo,v
	      Records	programs   for	 editing/validating  `cvs
	      commit' log entries.

       CVSROOT/history
	      Log file of cvs transactions.

       CVSROOT/loginfo,v
	      Records  programs  for  piping  `cvs  commit'   log
	      entries.

       CVSROOT/modules,v
	      Definitions for modules in this repository.

       CVSROOT/rcsinfo,v
	      Records  pathnames  to templates used during a `cvs
	      commit' operation.

       CVSROOT/taginfo,v
	      Records programs for validating/logging  `cvs  tag'
	      and `cvs rtag' operations.

       MODULE/Attic
	      Directory for removed source files.

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

       #cvs.tfl.pid
	      Temporary lock file for repository.

       #cvs.rfl.pid
	      A read lock.

       #cvs.wfl.pid
	      A write lock.

							       27

CVS(1)							   CVS(1)

ENVIRONMENT
       CVSROOT
	      Should contain the full pathname to the root of the
	      cvs  source  repository  (where  the  RCS files are
	      kept).  This information must be available  to  cvs
	      for  most  commands  to  execute; if CVSROOT is not
	      set, or if you wish to override it for one  invoca­
	      tion,  you  can supply it on the command line: `cvs
	      -d cvsroot cvs_command...' You may not need to  set
	      CVSROOT  if your cvs binary has the right path com­
	      piled in.

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

       CVSREADONLYFS
	      If  this	is set, the -R option is assumed, and cvs
	      operates in read-only repository mode.

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

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

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

       CVS_OPTIONS
	      Specifies a set of default options for cvs.   These
	      options  are  interpreted  before  the startup file
	      (~/.cvsrc)  is  read  and  can  be  overridden   by
	      explicit command line parameters.

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

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

							       28

CVS(1)							   CVS(1)

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

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

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

       Jeff Polk
	      Helped  Brian with the design of the cvs module and
	      vendor branch support and author of the  checkin(1)
	      shell script (the ancestor of `cvs import').

       And many others too numerous to mention here.

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

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

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

							       29


NAME | SYNOPSIS | NOTE | DESCRIPTION | ESSENTIAL COMMANDS | OPTIONS | CVS OPTIONS | USAGE | CVS STARTUP FILE | CVS COMMAND SUMMARY | COMMON COMMAND OPTIONS | CVS COMMANDS | FILES | ENVIRONMENT | AUTHORS | SEE ALSO

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=cvs&manpath=FreeBSD+4.2-RELEASE>

home | help