👤
Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

RedHat 9 (Linux i386) - man page for cvs (redhat section 1)

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  man-
       ual  (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 operate on one file at a time or one  direc-
       tory at a time, but operates on hierarchical collections of directories consisting of ver-
       sion 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	``reposi-
       tory''; 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 master every detail to do useful work with  cvs;
       in fact, five commands are sufficient to use (and contribute to) the source repository.

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

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

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

       cvs remove file...
	      Use this command (after erasing any files listed) to declare that you wish to elim-
	      inate 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_com-
       mand.   The  same  option  can  mean  different	things	depending on whether it is in the
       cvs_options position (to the left of a cvs command) or in the command_options position (to
       the right of a cvs command).

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

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

       Use these options to control the overall cvs program:

       -H [ --help ]
	      Display usage information about the specified cvs_command (but do not actually exe-
	      cute the command).  If you don't specify a command name, `cvs -H' displays  a  sum-
	      mary 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; informational messages, such as reports of
	      recursion through subdirectories, are suppressed.

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

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

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

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

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

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

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

       -r     Makes new working files read-only.  Same effect as if the CVSREAD environment vari-
	      able 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 compres-
	      sion-level to compress and de-compress data as it  is  transferred.   Requires  the
	      presence	of  the  GNU  gzip program in the current search path at both ends of the
	      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.  However, many options are available across  sev-
       eral  commands.	 You  can  display  a usage summary for each command by specifying 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 arguments, one command per line.  For
       example, the following line in .cvsrc:

       diff -c

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

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

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

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

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

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

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

       export Prepare copies of a set of source files for shipment off site.  Differs  from  `cvs
	      checkout' in that no cvs administrative directories are created (and therefore `cvs
	      commit' cannot be executed from a directory prepared with `cvs export'), and a sym-
	      bolic  tag must be specified.  (Does not change repository; creates directory simi-
	      lar 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  `$CVS-
	      ROOT/CVSROOT/history' file; see cvs(5).

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

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

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

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

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

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

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

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

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

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

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

       -D date_spec
	      Use the most recent revision no later  than  date_spec  (a  single  argument,  date
	      description  specifying  a  date	in the past).  A wide variety of date formats are
	      supported, in particular	ISO  ("1972-09-24  20:05")  or	Internet  ("24	Sep  1972
	      20:05").	 The  date_spec  is  interpreted as being in the local timezone, unless a
	      specific timezone is specified.  The specification is ``sticky'' when you use it to
	      make  a  private	copy of a source file; that is, when you get a working file using
	      -D, cvs records the date you specified, so that further updates in the same  direc-
	      tory will use the same date (unless you explicitly override it; see the description
	      of the update command).  -D is available with the checkout, diff, history,  export,
	      rdiff, rtag, and update commands.  Examples of valid date specifications include:
			1 month ago
			2 hours ago
			400000 seconds ago
			last year
			last Monday
			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  speci-
	      fied.   Use  the	-f option if you want files retrieved even when there is no match
	      for the tag or date.  (The most recent version is used in this situation.)   -f  is
	      available with these commands: checkout, export, rdiff, rtag, and update.

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

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

       -l     Local; run only in current working directory, rather than recurring through  subdi-
	      rectories.   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  writ-
	      ing  them  in  the  current directory.  Available with the checkout and update com-
	      mands.

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

	      The tag specification is ``sticky'' when you use this option with `cvs checkout' or
	      `cvs  update'  to make your own copy of a file: cvs remembers the tag and continues
	      to use it on future update commands, until  you  specify	otherwise.   tag  can  be
	      either  a  symbolic or numeric tag.  Specifying the -q global option along with the
	      -r command option is often useful, to suppress the warning messages  when  the  RCS
	      file  does  not contain the specified tag.  -r is available with the checkout, com-
	      mit, 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 sum-
       mary 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 reposi-
		 tory.	Also, some commands change the repository, some change the working direc-
		 tory, 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 directory in the source repository.
	      The files or directories specified with add  must  already  exist  in  the  current
	      directory (which must have been created with the checkout command).  To add a whole
	      new directory hierarchy to the source repository (for example, files received  from
	      a third-party vendor), use the `cvs import' command instead.

	      If the argument to `cvs add' refers to an immediate sub-directory, the directory is
	      created at the correct place in the source repository, and the necessary cvs admin-
	      istration  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 par-
	      ticular directory to your private sources even if someone else created that  direc-
	      tory after your checkout of the sources.	You can do the following:

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

	      An alternate approach using `cvs update' might be:

			example% cvs update -d new_directory

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

	      The added files are not placed in the source repository until you use `cvs  commit'
	      to  make	the  change permanent.	Doing a `cvs add' on a file that was removed with
	      the `cvs remove' command will resurrect the file, if no `cvs commit' command 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  creation of the file (for example, to describe the
	      file's purpose), you can specify it with the `-m message' option to  the	add  com-
	      mand.

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

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

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

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

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

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

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

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

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

	      Use the -A option to reset any sticky tags, dates, or -k options.  (If  you  get	a
	      working  file using one of the -r, -D, or -k options, cvs remembers the correspond-
	      ing 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 revi-
	      sions.  This can be used to ``remove'' a certain delta from your working file.

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

			example% cvs checkout -jTAG:yesterday -jTAG module

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

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

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

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

       commit [-lnR] [-m 'log_message' | -F file] [-r revision] [files...]
	      Requires: working directory, repository.
	      Changes: repository.
	      Synonym: ci
	      Use  `cvs  commit'  when	you  want to incorporate changes from your working source
	      files into the general source repository.

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

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

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

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

			example% cvs commit -r3.0

	      cvs  will only allow you to commit to a revision that is on the main trunk (a revi-
	      sion with a single dot).	However, you can also commit to a  branch  revision  (one
	      that  has an even number of dots) with the -r option.  To create a branch revision,
	      one typically use the -b option of the rtag or tag commands.  Then, either checkout
	      or  update can be used to base your sources on the newly created branch.	From that
	      point on, all commit changes made within these working sources  will  be	automati-
	      cally  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 prod-
	      uct, even though the 2.0 version is already under development, you might do:

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

	      Say  you	have been working on some extremely experimental software, based on what-
	      ever 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 develop-
	      ment, you could commit your change to a new branch.  Others can then checkout  your
	      experimental  stuff  and	utilize the full benefit of cvs conflict resolution.  The
	      scenario might look like:

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

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

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

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

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

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

	      The  only  non-standard  options are `-d dir' (write the source into directory dir)
	      and `-N' (don't shorten module paths).  These have the same meanings  as	the  same
	      options in `cvs 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 informa-
	      tion 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 modi-
		 fied).

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

	     -o  Report on checked-out modules.

	     -T  Report on all tags.

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

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

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

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

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

	     -l  Show last modification only.

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

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

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

	     -D date
		 Show data since date.

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

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

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

	     -u name
		 Show records for user name.

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

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

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

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

	      The outside source is saved in a first-level branch, by default  `1.1.1'.   Updates
	      are leaves of this branch; for example, files from the first imported collection of
	      source will be revision `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 col-
	      lection of source.  vendortag is a tag for the entire branch (e.g.,  for	`1.1.1').
	      You  must  also specify at least one releasetag to identify the files at the leaves
	      created each time you execute `cvs import'.

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

	      There are three additional special options.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       remove [-lR] [files...]
	      Requires: Working directory.
	      Changes: Working directory.
	      Synonyms: rm, delete
	      Use  this  command to declare that you wish to remove files from the source reposi-
	      tory.  Like most cvs commands, `cvs remove' works on files in your  working  direc-
	      tory,  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 recur-
	      sion, 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  speci-
	      fied  source  versions in the repository.  `cvs rtag' works directly on the reposi-
	      tory contents (and requires no prior checkout).  Use `cvs tag' instead, to base the
	      selection of versions to tag on the contents of your working directory.

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

	      `cvs  rtag'  will not move a tag that already exists.  With the -F option, however,
	      `cvs rtag' will re-locate any instance of 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  mes-
	      sage.

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

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

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

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

	      Use the -a option to have rtag look in the `Attic' for removed files  that  contain
	      the  specified tag.  The tag is removed from these files, which makes it convenient
	      to re-use a symbolic tag as development continues (and files get removed	from  the
	      up-coming 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 subdi-
	      rectories) with the standard -l option flag; or you can explicitly  request  recur-
	      sive 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] symbolic_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  reposi-
	      tory  is	that  you  are	tagging  the  checked-in revisions, which may differ from
	      locally modified files in your working directory.  If you want to avoid doing  this
	      by  mistake,  specify  the -c option to cvs tag.	If there are any locally modified
	      files, CVS will abort with an error before it tags any files.

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

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

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

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

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

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

	      `cvs tag' will not move a tag that already exists.  With the  -F	option,  however,
	      `cvs  tag'  will re-locate any instance of 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 devel-
	      opment.  This is most useful for creating a patch to a previously released software
	      distribution.

	      Normally,  tag executes recursively through subdirectories; you can prevent this by
	      using the standard -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 reconcile your work with any revi-
	      sions applied to	the source repository since your last checkout or update.

	      update keeps you informed of its progress by printing a line for each  file,  pref-
	      aced 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 accom-
		 plishes 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 modifications  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 successfully, 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 working  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 automat-
		 ically 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  revi-
	    sions.  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 specific 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 pat-
	    terns; for an up to date list of ignored file names, see the  Cederqvist  manual  (as
	    described in the SEE ALSO section 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 modified 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  CVS-
	      ROOT/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
	      CVSROOT 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 cre-
	      ated/updated when you specify -r or -D to the checkout or update commands,  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 repository.

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

       CVSROOT/cvswrappers,v
	      Records  cvs  wrapper  commands  to be used when checking 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 sensitive changes to the source reposi-
	      tory.

       #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 com-
	      mands to execute; if CVSROOT is not set, or if you wish  to  override  it  for  one
	      invocation,  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 compiled  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 modi-
	      fication of your working files.

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

       CVSEDITOR
	      Specifies the program to use for recording log messages 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 com-
	      mand.  If this variable 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  addition  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 resolu-
	      tion 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 Management with CVS by Per Cederqvist  et
       al.   Depending	on your system, you may be able to get it with the info cvs command or it
       may be available as cvs.ps (postscript), cvs.texinfo (texinfo source), or cvs.html.

       For CVS updates, more information on documentation, software 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)


All times are GMT -4. The time now is 07:04 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
×
UNIX.COM Login
Username:
Password:  
Show Password