cvs - Concurrent Versions System
cvs [ cvs_options ]
cvs_command [ command_options ] [ command_args ]
This manpage is a summary of some of the features of cvs
but it may no longer be kept up-to-date. For more current
and in-depth documentation, please consult the Cederqvist
manual (via the info cvs command or otherwise, as
described in the SEE ALSO section of this manpage).
CVS is a version control system, which allows you to keep
old versions of files (usually source code), keep a log of
who, when, and why changes occurred, etc., like RCS or
SCCS. Unlike the simpler systems, CVS does not just 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.
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 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 add file...
Use this command to enroll new files in cvs records
of your working directory. The files will be added
to the repository the next time you run `cvs
commit'. Note: You should use the `cvs import'
command to bootstrap new sources into the source
repository. `cvs add' is only used for new files
to an already checked-out module.
cvs remove file...
Use this command (after erasing any files listed)
to declare that you wish to eliminate files from
the repository. The removal does not affect others
until you run `cvs commit'.
cvs commit file...
Use this command when you wish to ``publish'' your
changes to other developers, by incorporating them
in the source repository.
The cvs command line can include cvs_options, which apply
to the overall cvs program; a cvs_command, which specifies
a particular action on the source repository; and com-
mand_options and command_arguments to fully specify what
the cvs_command will do.
Warning: you must be careful of precisely where you place
options relative to the cvs_command. The same option can
mean different things depending on whether it is in the
cvs_options position (to the left of a cvs command) or in
the command_options position (to the right of a cvs command).
There are only two situations where you may omit cvs_com-
mand: `cvs -H' or `cvs --help' elicits a list of available
commands, and `cvs -v' or `cvs --version' displays version
information on cvs itself.
As of release 1.6, cvs supports GNU style long options as
well as short options. Only a few long options are 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, `cvs
-H' displays a summary of all the commands available.
-Q Causes the command to be really quiet; the command
will generate output only for serious problems.
-q Causes the command to be somewhat quiet; 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 repository. Overrides
the setting of the CVSROOT environment variable.
This value should be specified as an absolute
pathname.
-D CVS_directory
Specify where cvs stores its bookkeeping files
(defaults to `CVS' as usual).
-e editor
Use editor to enter revision log information.
Overrides the setting of the CVSEDITOR, VISUAL, and
EDITOR environment variables.
-f Do not read the cvs startup file (~/.cvsrc).
-l Do not log the cvs_command in the command history
(but execute it anyway). See the description of
the history command for information on command 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.
-z compression-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.
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 several commands.
You can display a usage summary for each command by specifying
the -H option with the command.
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' ).
Global options are specified using the cvs keyword. For
example, the following:
cvs -q
will mean that all `cvs' commands will behave as thought
he -q global option had been supplied.
Here are brief descriptions of all the cvs commands:
add Add a new file or directory to the repository,
pending a `cvs commit' on the same file. Can only
be done from within sources created by a previous
`cvs checkout' invocation. Use `cvs import' to
place whole new hierarchies of sources under cvs
control. (Does not directly affect repository;
changes working directory.)
admin Execute control functions on the source repository.
(Changes repository directly; uses working 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 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 `$CVSROOT/CVS-
ROOT/history' file; see cvs(5).
import Incorporate a set of updates from off-site into the
source repository, as a ``vendor branch''.
(Changes repository.)
init Initialize a repository by adding the CVSROOT subdirectory
and some default control files. You must
use this command or initialize the repository in
some other way before you can use it.
log Display log information. (Does not change 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 `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 [Toc] [Back] 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 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.
-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 subdirectories.
Available with the following commands: checkout,
commit, diff, export, remove, rdiff, rtag, status,
tag, and update. Warning: this is not the same as
the overall `cvs -l' option, which you can specify
to the left of a cvs command!
-n Do not run any checkout/commit/tag/update program.
(A program can be specified to run on each of these
activities, in the modules database; this option
bypasses it.) Available with the checkout, commit,
export, and rtag commands. Warning: this is not
the same as the overall `cvs -n' option, which you
can specify to the left of a cvs command!
-P Prune (remove) directories that are empty after
being updated, on checkout, or update. Normally,
an empty directory (one that is void of revisioncontrolled
files) is left alone. Specifying -P
will cause these directories to be silently removed
from your checked-out sources. This does not
remove the directory from the repository, only from
your checked out copy. Note that this option is
implied by the -r or -D options of checkout and
export.
-p Pipe the files retrieved from the repository to
standard output, rather than writing them in the
current directory. Available with the checkout and
update commands.
-r tag Use the revision specified by the tag argument
instead of the default ``head'' revision. As well
as arbitrary tags defined with the tag or rtag command,
two special tags are always available: `HEAD'
refers to the most recent version available in the
repository, and `BASE' refers to the revision you
last checked out into the current working 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, commit, diff, history,
export, rdiff, rtag, and update commands. Warning:
this is not the same as the overall `cvs -r'
option, which you can specify to the left of a cvs
command!
Here (finally) are details on all the cvs commands and the
options each accepts. The summary lines at the top of
each command's description highlight three kinds of
things:
Command Options and Arguments
Special options are described in detail below;
common command options may appear only in the
summary line.
Working Directory, or Repository?
Some cvs commands require a working directory to
operate; some require a repository. Also, some
commands change the repository, some change the
working directory, and some change nothing.
Synonyms
Many commands have synonyms, which you may find
easier to remember (or type) than the principal
name.
add [-k kflag] [-m 'message'] files...
Requires: repository, working directory.
Changes: working directory.
Synonym: new
Use the add command to create a new file or 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 administration files are created in your
working directory. If the directory already exists
in the source repository, `cvs add' still creates
the administration files in your version of the
directory. This allows you to use `cvs add' to add
a particular directory to your private sources even
if someone else created that directory after your
checkout of the sources. You can do the following:
example% mkdir new_directory
example% cvs add new_directory
example% cvs update new_directory
An alternate approach using `cvs update' might be:
example% cvs update -d new_directory
(To add any available new directories to your working
directory, it's probably simpler 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 intervened.
You will have the opportunity to specify a logging
message, as usual, when you use `cvs commit' to
make the new file permanent. If you'd like to have
another logging message associated with just cre-
ation of the file (for example, to describe the
file's purpose), you can specify it with the `-m
message' option to the add command.
The `-k kflag' option specifies the default way
that this file will be checked out. The `kflag'
argument is stored in the RCS file and can be
changed with `cvs admin'. Specifying `-ko' is 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
`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 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 `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
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 `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 disabling recursion (you can
turn it back on with -R of course).
commit verifies that the selected files are up to
date with the current revisions in the source
repository; it will notify you, and exit without
committing, if any of the specified files must be
made current first with `cvs update'. commit does
not call the update command for you, but rather
leaves that for you to do when the time is right.
When all is well, an editor is invoked to allow you
to enter a log message that will be written to one
or more logging programs and placed in the source
repository file. You can instead specify the log
message on the command line with the -m option,
thus suppressing the editor invocation, or use the
-F option to specify that the argument file 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 mainline
development in any way. For example, if you
had to create a patch to the 1.2 version of the
product, even though the 2.0 version is already
under development, you might do:
example% cvs rtag -b -rFCS1_2 FCS1_2_Patch product_module
example% cvs checkout -rFCS1_2_Patch product_module
example% cd product_module
[[ hack away ]]
example% cvs commit
Say you have been working on some extremely 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:
example% cvs tag -b EXPR1
example% cvs update -rEXPR1
[[ hack away ]]
example% cvs commit
Others would simply do `cvs checkout -rEXPR1 what-
ever_module' to work with you on the experimental
change.
diff [-kl] [rcsdiff_options] [[-r rev1 | -D date1] [-r
rev2 | -D date2]] [files...]
Requires: working directory, repository.
Changes: nothing.
You can compare your working files with revisions
in the source repository, with the `cvs diff' 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] mod-
ule...
Requires: repository.
Changes: current directory.
This command is a variant of `cvs checkout'; use it
when you want a copy of the source for module 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 information in various formats.
Warning: `cvs history' uses `-f', `-l', `-n', and
`-p' in ways that conflict with the descriptions in
COMMON COMMAND OPTIONS.
Several options (shown above as -report) control
what kind of report is generated:
-c Report on each time commit was used (i.e., each
time the repository was modified).
-m module
Report on a particular module. (You can 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 commands have a single record
type: checkout (type `O'), release (type `F'),
and rtag (type `T'). One of four record types
may result from an update: `W', when the working
copy of a file is deleted during update (because
it was gone from the repository); `U', when a
working file was copied from the repository;
`G', when a merge was necessary and it 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 example, +0530 stands
for 5 hours and 30 minutes ahead of (i.e. east
of) UTC.
The options shown as -flags constrain the report
without requiring option arguments:
-a Show data for all users (the default is to show
data only for the user executing `cvs history').
-l Show last modification only.
-w Show only the records for modifications done
from the same working directory where `cvs his-
tory' is executing.
The options shown as -options args constrain the
report based on an argument:
-b str
Show data back to a record containing the string
str in either the module name, the file name, or
the repository path.
-D date
Show data since date.
-p repository
Show data for a particular source repository
(you can specify several -p options on the same
command line).
-r rev
Show records referring to revisions since the
revision or tag named rev appears in individual
RCS files. Each RCS file is searched for the
revision or tag.
-t tag
Show records since tag tag was last added to the
history file. This differs from the -r flag
above in that it reads only the history file,
not the RCS files, and is much faster.
-u name
Show records for user name.
import [-options] repository vendortag releasetag...
Requires: Repository, source distribution 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 differences, 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 collection of source.
vendortag is a tag for the entire branch (e.g., for
`1.1.1'). You must also specify at least one
releasetag to identify the files at the leaves 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]] mod-
ules...
Requires: repository.
Changes: nothing.
Synonym: patch
Builds a Larry Wall format patch(1) file between
two releases, that can be fed directly into the
patch program to bring an old release up-to-date
with the new release. (This is one of the few cvs
commands that operates directly from the 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 `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-committed changes are
present; that you are executing it from immediately
above, or inside, a cvs working directory; and that
the repository recorded for your files is the same
as the repository defined in the module database.
If all these conditions are true, `cvs release'
leaves a record of its execution (attesting to your
intentionally abandoning your checkout) in the cvs
history log.
You can use the -d flag to request that your 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, `cvs remove' 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 `Attic' directory
(also within the source repository).
This command is recursive by default, scheduling
all physically removed files that it finds for
removal by the next commit. Use the -l option to
avoid this recursion, or just specify that actual
files that you wish remove to consider.
rtag [-falnRQq] [-b] [-d] [-r tag | -D date] symbolic_tag
modules...
Requires: repository.
Changes: repository.
Synonym: rfreeze
You can use this command to assign symbolic tags to
particular, explicitly specified source versions in
the repository. `cvs rtag' works directly on the
repository contents (and requires no prior check-
out). Use `cvs tag' instead, to base the selection
of versions to tag on the contents of your working
directory.
In general, tags (often the symbolic names of 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 relocate
any instance of symbolic_tag that already
exists on that file to the new repository versions.
Without the -F option, attempting to use `cvs rtag'
to apply a tag that already exists on that file
will produce an error message.
The -b option makes the tag a ``branch'' tag,
allowing concurrent, isolated development. This is
most useful for creating a patch to a previously
released software distribution.
You can use the standard -r and -D options to tag
only those files that already contain a certain
tag. This method would be used to rename a tag:
tag only the files identified by the old tag, then
delete the old tag, leaving the new tag on exactly
the same files as the old tag.
rtag executes recursively by default, tagging all
subdirectories of modules you specify in the 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 subdirectories) with the
standard -l option flag; or you can explicitly
request recursive status reports with the -R
option.
The -v option causes the symbolic tags for the RCS
file to be displayed as well.
tag [-lQqR] [-F] [-b] [-d] [-r tag | -D date] [-f] sym-
bolic_tag [files...]
Requires: working directory, repository.
Changes: repository.
Synonym: freeze
Use this command to assign symbolic tags to the
nearest repository versions to your working
sources. The tags are applied immediately to the
repository, as with rtag.
One potentially surprising aspect of the fact that
cvs tag operates on the repository is that you are
tagging the checked-in revisions, which may differ
from locally modified files in your working 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 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 `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
|
