This manpage is a summary of some of the features of
cvs
but for more in-depth documentation, consult the Cederqvist manual (as
described in the SEE ALSO section of this manpage).
DESCRIPTION
CVS is a version control system, which allows you to keep old versions
of files (usually source code), keep a log of who, when, and why
changes occurred, etc., like RCS or SCCS. Unlike the simpler systems,
CVS does not just operate on one file at a time or one directory at a
time, but operates on hierarchical collections of directories
consisting of version controlled files. CVS helps to manage releases
and to control the concurrent editing of source files among multiple
authors. CVS allows triggers to enable/log/control various
operations and works well over a wide area network.
cvs
keeps a single copy of the master sources.
This copy is called the source ``repository''; it contains all the
information to permit extracting previous software releases at any
time based on either a symbolic revision tag, or a date in the past.
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 checkoutmodules...
A necessary preliminary for most cvs work: creates your private
copy of the source for modules (named collections of source; you
can also use a path relative to the source repository here). You can
work with this copy without interfering with others' work. At least
one subdirectory level is always created.
cvs update
Execute this command from within your private source
directory when you wish to update your copies of source files from
changes that other developers have made to the source in the
repository.
cvs addfile...
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
Note:
You should use the
command to bootstrap new sources into the source repository.
is only used for new files to an already checked-out module.
cvs removefile...
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 commitfile...
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
command_options
and
command_arguments
to fully specify what the
cvs_command
will do.
Warning:
you must be careful of precisely where you place options relative to the
cvs_command.
The same option can mean different things depending on whether it
is in the
cvs_options
position (to the left of a
cvs
command) or in the
command_options
position (to the right of a
cvs
command).
There are only two situations where you may omit
cvs_command:
or
elicits a list of available commands, and
or
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 execute the command). If you don't specify a
command name,
displays a summary of all the commands available.
-Q
Causes the command to be
really
quiet; the command will generate output only for serious problems.
-q
Causes the command to be somewhat quiet; informational messages, such
as reports of recursion through subdirectories, are suppressed.
-bbindir
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.
-dCVS_root_directory
Use
CVS_root_directory
as the root directory pathname of the master
source repository.
Overrides the setting of the
CVSROOT
environment variable.
This value should be specified as an absolute pathname.
-eeditor
Use
editor
to enter revision log information.
Overrides the setting of the
CVSEDITOR,
VISUAL, and
EDITOR
environment variables.
-f
Do not read the
cvs
startup file (~/.cvsrc).
-l
Do not log the
cvs_command
in the command history (but execute it anyway). See the description
of the
history
command for information on command history.
-n
Do not change any files. Attempt to execute the
cvs_command,
but only to issue reports; do not remove, update, or merge any
existing files, or create any new files.
-t
Trace program execution; display messages showing the steps of
cvs
activity. Particularly useful with
-n
to explore the potential impact of an unfamiliar command.
-r
Makes new working files read-only.
Same effect as if the
CVSREAD
environment variable is set.
-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.
-zcompression-level
When transferring files across the network use
gzip
with compression level compression-level to compress and
de-compress data as it is transferred. Requires the presence of
the
GNU
gzip
program in the current search path at both ends of the link.
USAGE
Except when requesting general help with
you must specify a
cvs_command
to
cvs
to select a specific release control function to perform.
Each
cvs
command accepts its own collection of options and arguments.
However, many options are available across several commands.
You can display a usage summary for each command by specifying the
-H
option with the command.
CVS STARTUP FILE
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
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 COMMAND SUMMARY
Here are brief descriptions of all the
cvs
commands:
add
Add a new file or directory to the repository, pending a
on the same file.
Can only be done from within sources created by a previous
invocation.
Use
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
in that no
cvs
administrative directories are created (and therefore
cannot be executed from a directory prepared with
and a symbolic 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
file; see
cvs(5).
import
Incorporate a set of updates from off-site into the source repository,
as a ``vendor branch''. (Changes repository.)
init
Initialize a repository by adding the CVSROOT subdirectory and some default
control files. You must use this command or initialize the repository in
some other way before you can use it.
log
Display
log information.
(Does not change repository or working 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
abandoning any changes.
(Can delete working directory; no effect on repository.)
remove
Remove files from the source repository, pending a
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
(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.
-Ddate_spec
Use the most recent revision no later than date_spec (a single
argument, date description specifying a date in the
past). A wide variety of date formats are supported, in particular
ISO ("1972-09-24 20:05") or Internet ("24 Sep 1972 20:05").
The date_spec is interpreted as being in the local timezone, unless a
specific timezone is specified.
The specification is ``sticky'' when you use it to make a
private copy of a source file; that is, when you get a working file
using -D, cvs records the date you
specified, so that further updates in the same directory will use the
same date (unless you explicitly override it; see the description of
the update command).
-D
is available with the
checkout, diff, history, export,
rdiff, rtag, and
update
commands.
Examples of valid date specifications include:
1 month ago
2 hours ago
400000 seconds ago
last year
last Monday
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.
-kkflag
Alter the default
processing of keywords.
The -k option is available with the
add, checkout, diff, export,
rdiff, and update
commands. Your kflag specification is ``sticky'' when you use
it to create a private copy of a source file; that is, when you use
this option with the checkout or update commands,
cvs associates your selected kflag with the file, and
continues to use it with future update commands on the same file
until you specify otherwise.
Some of the more useful kflags are -ko and -kb (for binary files),
and -kv which is useful for an
export
where you wish to retain keyword information after an
import
at some other site.
-l
Local; run only in current working directory, rather than recurring through
subdirectories. Available with the following commands:
checkout, commit, diff,
export, remove, rdiff, rtag,
status, tag, and update.
Warning:
this is not the same
as the overall
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
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.
-rtag
Use the revision specified by the
tag
argument instead of the default ``head'' revision. As well as
arbitrary tags defined with the tag or rtag command, two
special tags are always available:
refers to the most
recent version available in the repository, and
refers to the revision you last checked out into the current working
directory.
The tag specification is ``sticky'' when you use
this option with
or
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
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 [-kkflag] [-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
command instead.
If the argument to
refers to an immediate sub-directory, the directory is
created at the correct place in the
source repository, and the necessary
cvs
administration files are created in your working directory.
If the directory already exists in the source repository,
still creates the administration files in your version of the directory.
This allows you to use
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:
(To add any available new directories to your working directory, it's
probably simpler to use
or
The added files are not placed in the
source repository until you use
to make the change permanent.
Doing a
on a file that was removed with the
command will resurrect the file, if no
command intervened.
You will have the opportunity to specify a logging message, as usual,
when you use
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
option to the
add
command.
The
option specifies the default way that this
file will be checked out.
The
argument is stored in the
RCS
file and can be changed with
Specifying
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
modules.
You must execute
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
in the source repository; see
cvs(5))
for some collection of source directories and files, or paths to
directories or files in the repository.
Depending on the
modules
you specify,
checkout
may recursively create directories and populate them with the appropriate
source files.
You can then edit these source files at any time (regardless of whether
other software developers are editing their own copies of the sources);
update them to include new changes applied by others to the source
repository; or commit your work as a permanent change to the
repository.
Note that
checkout
is used to create directories.
The top-level directory created is always added to the directory
where
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
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
include the standard command options
-P, -f,
-k kflag
,
-l, -n, -p,
-rtag, 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 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
tells you to do when you have
just imported sources that have conflicts with local changes:
Use the
-N
option with
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.
Requires:
working directory, repository.
Changes:
repository.
Synonym:ci
Use
when you want to incorporate changes from your working source
files into the general source repository.
If you don't specify particular files to commit, all
of the files in your working current directory are examined.
commit
is careful to change in the repository only those files that you have
really changed. By default (or if you explicitly specify the
-R
option), files
in subdirectories are also examined and committed if they have
changed; you can use the
-l
option to limit
commit
to the current directory only.
Sometimes you may want to force a file to be committed even though it
is unchanged; this is achieved with the
-f
flag, which also has the effect of disabling recursion (you can turn
it back on with
-R
of course).
commit
verifies that the selected files are up to date with the current revisions
in the source repository; it will notify you, and exit without
committing, if any of the specified files must be made current first
with
commit
does not call the
update
command for you, but rather leaves that for you to do when
the time is right.
When all is well, an editor is invoked to allow you to enter a log
message that will be written to one or more logging programs and placed in the
source repository file.
You can instead specify the log message on the command line with the
-m
option, thus suppressing the editor invocation, or use the
-F
option to specify that the argument file contains the log message.
The
-r
option can be used to commit to a particular symbolic or numeric revision.
For example, to bring all your files up to the
revision ``3.0'' (including those that haven't changed), you might do:
example% cvs commit -r3.0
cvs
will only allow you to commit to a revision that is on the main trunk (a
revision with a single dot).
However, you can also commit to a branch revision (one that has an even
number of dots) with the
-r
option.
To create a branch revision, one typically use the
-b
option of the
rtag or tag
commands.
Then, either
checkout or update
can be used to base your sources on the newly created branch.
From that point on, all
commit
changes made within these working sources will be automatically added
to a branch revision, thereby not perturbing main-line development in any
way.
For example, if you had to create a patch to the 1.2 version of the
product, even though the 2.0 version is already under development, you
might do:
Say you have been working on some extremely experimental software, based on
whatever revision you happened to checkout last week.
If others in your group would like to work on this software with you, but
without disturbing main-line development, you could commit your change to a
new branch.
Others can then checkout your experimental stuff and utilize the full
benefit of
cvs
conflict resolution.
The scenario might look like:
Requires:
working directory, repository.
Changes:
nothing.
You can compare your working files with revisions in the source
repository, with the
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.
Requires:
repository.
Changes:
current directory.
This command is a variant of
use it when you want a copy of the source for module
without the cvs administrative directories. For example, you
might use
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
(write the
source into directory dir) and
(don't shorten
module paths).
These have the same meanings as the same options in
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
and are described in
co(1).
history [-report] [-flags] [-options args] [files...]
Requires:
the file
Changes:
nothing.
cvs keeps a history file that tracks each use of the
checkout, commit, rtag, update, and release
commands. You can use
to display this
information in various formats.
Warning:
uses
and
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).
-mmodule
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.
-xtype
Extract a particular set of record types X from the cvs
history. The types are indicated by single letters, which you may
specify in combination.
Certain commands have a single record type: checkout (type `O'),
release (type `F'), and rtag (type `T'). One of four
record types may result from an update: `W', when the working copy
of a file is deleted during update (because it was gone from the
repository); `U', when a working file was copied from the
repository; `P', like `U', but the CVS server sent a patch instead of
the whole file; `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
-zzone
Use time zone
zone
when outputting history records.
The zone name
LT
stands for local time;
numeric offsets stand for hours and minutes ahead of UTC.
For example,
+0530
stands for 5 hours and 30 minutes ahead of (i.e. east of) UTC.
The options shown as -flags constrain the report without
requiring option arguments:
-a
Show data for all users (the default is to show data only for the user
executing
-l
Show last modification only.
-w
Show only the records for modifications done from the same working
directory where
is executing.
The options shown as -options args constrain the report
based on an argument:
-bstr
Show data back to a record containing the string str in either
the module name, the file name, or the repository path.
-Ddate
Show data since date.
-prepository
Show data for a particular source repository (you can specify several
-p options on the same command line).
-rrev
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.
-ttag
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.
Requires:
Repository, source distribution directory.
Changes:
repository.
Use
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
to reconcile the differences, as import instructs you to do.
By default, certain file names are ignored during
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
Updates are leaves of this
branch; for example, files from the first imported collection of
source will be revision
then files from the first
imported update will be revision
and so on.
At least three arguments are required. repository is needed to
identify the collection of source. vendortag is a tag for the
entire branch (e.g., for
You must also specify at
least one releasetag to identify the files at the leaves created
each time you execute
One of the standard
cvs
command options is available: -mmessage. 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
to specify that each file's time of last modification should be used
for the checkin date and time.
Use
to specify a first-level branch other
than
Use
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
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.
Requires:
repository.
Changes:
nothing.
Synonym:patch
Builds a Larry Wall format
patch(1)
file between two releases, that can be fed directly into the
patch
program to bring an old release up-to-date with the new release.
(This is one of the few cvs commands that operates directly from
the repository, and doesn't require a prior
checkout.)
The diff output is sent to the standard output device.
You can specify (using the standard -r and -D options)
any combination of one or two revisions or dates.
If only one revision or date is specified, the
patch file reflects differences between that revision or date and the
current ``head'' revisions in the
RCS
file.
Note that if the software release affected
is contained in more than one directory, then it may be necessary to
specify the
-p
option to the
patch
command when patching the old sources, so that
patch
is able to find the files that are located in other 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
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
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
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,
leaves a
record of its execution (attesting to your intentionally abandoning
your checkout) in the
cvs
history log.
You can use the -d flag to request that your working copies of
the source files be deleted if the release succeeds.
remove [-lR] [files...]
Requires:
Working directory.
Changes:
Working directory.
Synonyms:rm, delete
Use this command to declare that you wish to remove files from
the source repository. Like most
cvs
commands,
works on files in your working
directory, not directly on the repository. As a safeguard, it also
requires that you first erase the specified files from your working
directory.
The files are not actually removed until you apply your changes to the
repository with
commit;
at that point, the corresponding
RCS
files in the source repository are
moved
into the
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.
Requires:
repository.
Changes:
repository.
Synonym:rfreeze
You can use this command to assign symbolic tags to particular,
explicitly specified source versions in the repository.
works directly on the repository contents (and requires no
prior
checkout).
Use
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).
will not move a tag that already exists. With the -F option,
however,
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
to apply a tag that already exists on that file will produce an error
message.
The -b option makes the tag a ``branch'' tag, allowing
concurrent, isolated development.
This is most useful for creating a patch to a previously released software
distribution.
You can use the standard -r and -D options to tag only those
files that already contain a certain tag. This method would be used
to rename a tag: tag only the files identified by the old tag, then delete the
old tag, leaving the new tag on exactly the same files as the old tag.
rtag
executes recursively by default, tagging all subdirectories of
modules you specify in the argument. You can restrict its
operation to top-level directories with the standard -l option;
or you can explicitly request recursion with -R.
The modules database can specify a program to execute whenever a tag
is specified; a typical use is to send electronic mail to a group of
interested parties. If you want to bypass that program, use the
standard -n option.
Use the
-a
option to have
rtag
look in the
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
operates until you reset them; see the
description of
You can also use this command to anticipate the potential impact of a
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.
Requires:
working directory, repository.
Changes:
repository.
Synonym:freeze
Use this command to assign symbolic tags to the nearest repository
versions to your working sources. The tags are applied immediately to
the repository, as with rtag.
One use for tags is to record a ``snapshot'' of the current sources
when the software freeze date of a project arrives. As bugs are fixed
after the freeze date, only those changed sources that are to be part
of the release need be re-tagged.
The symbolic tags are meant to permanently record which revisions of which
files were used in creating a software distribution.
The
checkout,
export
and
update
commands allow you to extract an exact copy of a tagged release at any time in
the future, regardless of whether files have been changed, added, or removed
since the release was tagged.
You can use the standard -r and -D options to tag only those
files that already contain a certain tag. This method would be used
to rename a tag: tag only the files identified by the old tag, then delete the
old tag, leaving the new tag on exactly the same files as the old tag.
Specifying the -f flag in addition to the -r or -D
flags will tag those files named on the command line even if they do not
contain the old tag or did not exist on the specified date.
By default (without a -r or -D flag)
the versions to be tagged are supplied
implicitly by the cvs records of your working files' history
rather than applied explicitly.
If you use
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.
will not move a tag that already exists. With the -F option,
however,
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
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 subdirectories; you can prevent this by
using the standard -l option, or specify the recursion
explicitly by using -R.
update [-ACdflPpQqR] [-d] [-rtag|-Ddate] 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
revisions 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,
prefaced with one of the characters
to indicate the status of the file:
Ufile
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.
Pfile
Like `U', but the CVS server sends a patch instead of an entire
file. These two things accomplish the same thing.
Afile
The file has been added to your private copy of the sources, and
will be added to the
source repository when you run
on the file.
This is a reminder to you that the file needs to be committed.
Rfile
The file has been removed from your private copy of the sources, and
will be removed from the
source repository when you run
on the file.
This is a reminder to you that the file needs to be committed.
Mfile
The file is modified in your working directory.
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.
Cfile
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 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 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 directories 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 -Iname 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 section of this manpage).
Use
to avoid ignoring any files at all.
Use the
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
will ensure that
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.Static
Flag: do not add more entries on
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 created/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/Update.prog
Name of program to run on
Files in source repositories:
$CVSROOT/CVSROOT
Directory of global administrative files for repository.
CVSROOT/commitinfo,v
Records programs for filtering
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
log entries.
CVSROOT/history
Log file of cvs transactions.
CVSROOT/loginfo,v
Records programs for piping
log entries.
CVSROOT/modules,v
Definitions for modules in this repository.
CVSROOT/rcsinfo,v
Records pathnames to templates used during a
operation.
CVSROOT/taginfo,v
Records programs for validating/logging
and
operations.
MODULE/Attic
Directory for removed source files.
#cvs.lock
A lock directory created by
cvs
when doing sensitive 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 invocation, you can
supply it on the command line:
You may not need to set
CVSROOT
if your cvs binary has the right path compiled in; use
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
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
is used.
CVS_SERVER
cvs
uses the contents of this variable to determine the name of the
cvs
server command. If this variable is not set then
is used.
CVSWRAPPERS
This variable is used by the
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 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
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.