cvs man page on IRIX

Man page or keyword search:  
man Server   31559 pages
apropos Keyword Search (all sections)
Output format
IRIX logo
[printable version]

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 it may no longer be kept up-to-date.	 For more current
       and  in-depth documentation, please consult the Cederqvist
       manual  (via  the  info	cvs  command  or  otherwise,   as
       described in the SEE ALSO section of this manpage).

DESCRIPTION
       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
	      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  com-
	      mand).   If  you don't specify a command name, `cvs
	      -H' displays a summary of all the	 commands  avail-
	      able.

       -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
	      pathname of the master  source  repository.   Over-
	      rides  the setting of the CVSROOT environment vari-
	      able.  This value should be specified as	an  abso-
	      lute pathname.

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

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

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

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

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

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

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

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

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

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

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

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

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

       diff -c

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

       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  ship-
	      ment off site.  Differs from `cvs checkout' in that
	      no cvs administrative directories are created  (and
	      therefore	 `cvs  commit'	cannot be executed from a
	      directory prepared with `cvs export'), and  a  sym-
	      bolic  tag  must	be  specified.	 (Does not change
	      repository; creates directory  similar  to  working
	      directories).

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

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

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

       log    Display  log information.	 (Does not change 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  syn-
	      chronized	 with  your working directory.	 (Changes
	      repository directly; uses working directory without
	      changing it.)

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

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

       -D date_spec
	      Use  the	most  recent  revision	no   later   than
	      date_spec	 (a  single  argument,	date  description
	      specifying a date in the past).  A wide variety  of
	      date  formats  are  supported,  in  particular  ISO
	      ("1972-09-24 20:05")  or	Internet  ("24	Sep  1972
	      20:05").	 The date_spec is interpreted as being in
	      the local timezone, unless a specific  timezone  is
	      specified.   The	specification  is ``sticky'' when
	      you use it to make a private copy of a source file;
	      that  is, when you get a working file using -D, cvs
	      records the date you  specified,	so  that  further
	      updates  in  the	same  directory will use the same
	      date (unless you explicitly override  it;	 see  the
	      description  of  the update command).  -D is avail-
	      able with	 the  checkout,	 diff,	history,  export,
	      rdiff,  rtag,  and  update  commands.   Examples of
	      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
	      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
	      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
	      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.

       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
	      execute `cvs checkout' before  using  most  of  the
	      other  cvs  commands, since most of them operate on
	      your working directory.

	      modules  are  either  symbolic  names   (themselves
	      defined  as  the	module	`modules'  in  the source
	      repository; see  cvs(5))	for  some  collection  of
	      source  directories and files, or paths to 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
	      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...]
	      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.
	      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
	      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
	      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] mod-
       ule...
	      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.)

	     -o	 Report on checked-out modules.

	     -T	 Report on all tags.

	     -x type
		 Extract  a particular set of record types X from
		 the cvs history.  The	types  are  indicated  by
		 single	  letters,   which  you	 may  specify  in
		 combination.  Certain	commands  have	a  single
		 record	 type: checkout (type `O'), release (type
		 `F'), and rtag (type `T').  One of  four  record
		 types	may  result from an update: `W', when the
		 working copy of a file is deleted during  update
		 (because  it was gone from the repository); `U',
		 when a working file was copied from the  reposi-
		 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	      Use  the -a option to have rtag look in the `Attic'
	      for removed files that contain the  specified  tag.
	      The tag is removed from these files, which makes it
	      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...'.)

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

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

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

       $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 com-
	      mit' 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.

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

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

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

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

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

       CVS_RSH
	      cvs uses the contents of this variable to determine
	      the  name	 of  the remote shell command to use when
	      starting a cvs server.  If this variable is not set
	      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.

       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://cvshome.org
		 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).

							   CVS(1)
[top]

List of man pages available for IRIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net