diff. The overall format of all CVS commands is:
cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
cvs
cvs_options
cvs_command
command_options
command_args
cvs_options and command_options. For
example, -q can often (but not always) be given
as both a cvs_option and a
command_option. -l, when given as a
cvs_option, only affect some of the commands.
When it is given as a command_option is has a
different meaning, and is accepted by more commands.
In other words, do not take the above categorization
too seriously. Look at the documentation instead.
-H
-Q
-q
-b bindir
$RCSBIN environment
variable and any precompiled directory. This value should be
specified as an absolute pathname.
-d cvs_root_directory
$CVSROOT environment variable. This value
should be specified as an absolute pathname.
-e editor
$EDITOR environment variable.
-l
-n
-t
-r
$CVSREAD environment variable is set
(@pxref{Environment variables}). The default is to
make working files writable.
-v
-w
$CVSREAD environment variable.
Files are created read-write, unless $CVSROOT is
set or -r is given.
Warning: the history command is an exception; it supports many options that conflict even with these standard options.
-D date_spec
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; cf. update).
A wide variety of date formats are supported by the underlying RCS facilities, similar to those described in co(1), but not exactly the same. The date_spec is interpreted as being in the local timezone, unless a specific timezone is specified. 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
-D is available with the checkout,
diff, export, history,
rdiff, rtag, and update
commands. (The history uses this option in a slightly
different way; cf. history options). Remember to quote argument to the -D flag so that your shell doesn't interpret the spaces as argument separators. A command using the -D flag can look like this:
$ cvs diff -D "1 hour ago" cvs.texinfo
-f
-f is available with these commands:
checkout, export, rdiff,
rtag, and update.
Warning: The commit command also has a
-f option, but it has a different meaning in
that command. cf. commit options.
-H
-k kflag
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.
The -k option is available with the
add, checkout, diff and
update commands.
-l
Warning: this is not the same as the overall cvs -l option, which you can specify to the left of a cvs command!
Available with the following commands: checkout,
commit, diff, export,
log, remove, rdiff,
rtag, status, tag, and
update.
-n
Warning: this is not the same as the overall cvs -n option, which you can specify to the left of a cvs command!
Available with the checkout, commit,
export, and rtag commands.
-m message
add,
commit and import.
-P
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
checkout and update commands.
-Q
checkout, import, export,
rdiff, rtag, tag, and
update.
-q
checkout,
import, export, rtag,
tag, and update.
-r tag
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 checkout or 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. The
tag can be either a symbolic or numeric tag. @xref{Tags}.
Specifying the -q option along with the -r option is often useful, to suppress the warning messages when the RCS history file does not contain the specified tag.
Warning: this is not the same as the overall `cvs -r' option, which you can specify to the left of a cvs command!
-r is available with the checkout,
commit, diff, history,
export, rdiff, rtag, and
update commands.
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 import command instead. cf.
import.
If the argument to 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, add still creates the
administration files in your version of the directory. This allows you
to use 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:
$ mkdir new_directory $ cvs add new_directory $ cvs update new_directoryAn alternate approach using
update might be:
$ cvs update -d new_directory(To add any available new directories to your working directory, it's probably simpler to use
checkout (cf.
checkout) or update -d (cf update)).
The added files are not placed in the source repository until you
use commit to make the change permanent. Doing an
add on a file that was removed with the remove
command will resurrect the file, unless a commit command
intervened.
cf. remove examples for an example.
Unlike most other commands add never recurses down
directories. It cannot yet handle relative paths. Instead of
$ cvs add foo/bar.cyou have to do
$ cd foo $ cvs add bar.c
-k kflag
admin.
Specifying -ko is useful for checking in binaries that
shouldn't have the RCS id strings expanded. Warning: this option is reported to be broken in version 1.3 and 1.3-s2 of CVS. Use admin -k after the commit instead. cf. admin.
-m description
log command displays this description.
The description can be changed using admin -t.
cf. admin.
If you omit the -m description flag,
an empty string will be used. You will not be prompted for a
description.
$ cvs add -m "Optimizer and code generation passes." backend.c $ cvs commit -m "Early version. Not yet compilable." backend.c
admin simply passes
all its options and arguments to the rcs command; it does
no filtering or other processing. This command does work
recursively, however, so extreme care should be used.
Since this command is seldom used, it is not documented here.
Complete documentation will appear here in the future.
admin command. It is
included to stress the fact that this command can be quite
dangerous unless you know exactly what you are doing.
The -o option can be used to outdate old revisions
from the history file. If you are short on disc this option
might help you. But think twice before using it --- there is no
way short of restoring the latest backup to undo this command!
The next line is an example of a command that you would
not like to execute.
$ cvs admin -o:R_1_02 .The above command will delete all revisions up to, and including, the revision that corresponds to the tag R_1_02. But beware! If there are files that have not changed between R_1_02 and R_1_03 the file will have the same numerical revision number assigned to the tags R_1_02 and R_1_03. So not only will it be impossible to retrieve R_1_02; R_1_03 will also have to be restored from the tapes! Example 2: I use ``cvs admin'' all the time for comment leaders on files that are currently not recognized (which then defaults to ``# ''). If you
cvs add then cvs commit a new file,
and you want to change the comment leader (to one for nroff source,
for example) I would use:
cvs admin -c'.\" ' *.man
Then, I have to remove the local version of the file (which still
has the ``# '' comment leader in it, even though ``cvs log'' says
it is '.\" ', and update it.
rm *.man
cvs update *.man # to get version with correct leaders.
checkout before using most of the other CVS
commands, since most of them operate on your working
directory.
The modules part of the command are either
symbolic names for some
collection of source directories and files, or paths to
directories or files in the repository. The symbolic
names are defined in the modules file.
@xref{modules}.
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 source 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 option).
Running 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. cf. update.
checkout
(cf. Common options, for a complete description of
them):
-D date
-f
-k kflag
status command can be viewed
to see the sticky options. cf. status.
-l
-n
-P
-p
-Q
-q
-r tag
checkout:
-A
-c
-d dir
-j tag
import
tells you to do when you have just imported sources
that have conflicts with local changes:
$ cvs checkout -jTAG:yesterday -jTAG module
-N
-s
$ cvs checkout tcGet a copy of the module tc as it looked one day ago:
$ cvs checkout -D yesterday tc
commit when you want to incorporate changes
from your working source files into the 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.
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 update (cf. 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
(@pxref{modules}, and @pxref{loginfo}) and placed in the RCS history
file inside the repository. This log message can be retrieved with the
log command; cf. log. You can specify the
log message on the command line with the -m message
option, and thus avoid the editor invocation, or use the
-[fF] file option to specify that the argument
file contains the log message.
commit
(@pxref{Common options}, for a complete description of
them):
-l
-n
-R
-r revision
commit also supports these options:
-F file
-f
Force CVS to commit a new revision even if you haven't made any changes to the file. If the current revision of file is 1.7, then the following two commands are equivalent:
$ cvs commit -f file $ cvs commit -r 1.8 file
-f file
Read the log message from file, instead of invoking an editor.
-m message
$ cvs commit -r 3.0Note that it is generally a bad idea to try to make the RCS revision number equal to the current release number of your product. You should think of the revision number as an internal number that the CVS package maintains, and that you generally never need to care much about. Using the
tag and rtag
commands you can give symbolic names to the releases
instead. cf tag and rtag.
Note that the number you specify with -r must be
larger than any existing revision number. That is, if
revision 3.0 exists, you cannot cvs commit
-r 1.3.
@appendixsubsubsec Committing to a branch
You can commit to a branch revision (one that has an
even number of dots) with the -r option. To
create a branch revision, use the -b option
of the rtag or tag commands (@pxref{tag}
or @pxref{rtag}). 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 disturbing 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:
$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module $ cvs checkout -r FCS1_2_Patch product_module $ cd product_module [[ hack away ]] $ cvs commitThis works automatically since the -r option is sticky.
@appendixsubsubsec Creating the branch after editing 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:
[[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs update -r EXPR1 $ cvs commitThe
update command will make the -r
EXPR1 option sticky on all files. Note that your
changes to the file will never be removed by the
update command. The commit will
automatically commit to the correct branch, because the
-r is sticky. You could also do like this:
[[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs commit -r EXPR1but then, only those files that were changed by you will have the -r EXPR1 sticky flag. If you hack away, and commit without specifying the -r EXPR1 flag, some files may accidentally end up on the main trunk.
To work with you on the experimental change, others would simply do
$ cvs checkout -r EXPR1 whatever_module
diff command is used to compare different
revisions of files. The default action is to compare
your working files with the revisions they were based
on, and report any differences that are found.
If any file names are given, only those files are
compared. If any directories are given, all files
under them will be compared.
The exit status will be 0 if no differences were found,
1 if some differences were found, and 2 if any error
occurred.
diff
(@pxref{Common options}, for a complete description of
them):
-D date
rcsdiff (which in turn passes it on
to diff. @sc{gnu} diff uses -D as a way to
put cpp-style #define statements around the output
differences. There is no way short of testing to
figure out how CVS was configured. In the default
configuration CVS will use the -D date option.
-k kflag
-l
-Q
-q
-R
-r tag
rcsdiff, which in turn passes them to
diff. The exact meaning of the options depends
on which diff you are using. The long options
introduced in @sc{gnu} diff 2.0 are not yet supported in
CVS. See the documentation for your diff to see
which options are supported.
$ cvs diff -kk -u -r 1.14 -r 1.19 backend.cSuppose the experimental branch EXPR1 was based on a set of files tagged RELEASE_1_0. To see what has happened on that branch, the following can be used:
$ cvs diff -r RELEASE_1_0 -r EXPR1A command like this can be used to produce a context diff between two releases:
$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffsIf you are maintaining ChangeLogs, a command like the following just before you commit your changes may help you write the ChangeLog entry. All local modifications that have not yet been committed will be printed.
$ cvs diff -u | less
checkout; use it
when you want a copy of the source for module without
the CVS administrative directories. For example, you
might use 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 keyword expansion option -kv is always set when
export is used. This causes any RCS keywords to be
expanded such that an import done at some other site
will not lose the keyword revision information. There
is no way to override this. Note that this breaks the
ident command (which is part of the RCS
suite---see ident(1)) which looks for RCS keyword
strings. If you want to be able to use ident
you must use checkout instead.
export
(@pxref{Common options}, for a complete description of
them):
-D date
-f
-l
-n
-Q
-q
-R
-r tag
checkout and export) are also supported:
-d dir
-N
checkout, commit, rtag,
update, and release commands. You can
use history to display this information in
various formats.
Logging must be enabled by creating the file
@file{$CVSROOT/CVSROOT/history}.
Warning: history uses
-f, -l, -n, and -p
in ways that conflict with the normal use inside CVS
(@pxref{Common options}).
-c
-e
-m module
-o
-T
-x type
F
O
T
C
G
U
W
A
M
R
-a
history).
-l
-w
history is executing.
-b str
-D date
-p repository
-r rev
-t tag
-u name
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
from the outside source. @xref{Tracking sources}, for
a discussion on this subject. 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 checkout -j to reconcile the differences, as import instructs you to do.
By default, certain file names are ignored during
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.
Currently, the default list of ignored files includes
files matching these names:
RCSLOG RCS SCCS
CVS* cvslog.*
tags TAGS
.make.state .nse_depinfo
*~ #* .#* ,*
*.old *.bak *.BAK *.orig *.rej .del-*
*.a *.o *.so *.Z *.elc *.ln
core
If the file @file{$CVSROOT/CVSROOT/cvsignore} exists,
any files whose names match the specifications in that
file will also be ignored. The outside source is saved in a first-level RCS 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 import.
import
(@pxref{Common options}, for a complete description of them):
-m message
-Q
-q
-b branch
-I name
name can be a file name pattern of the same type that you can specify in the @file{.cvsignore} file. @xref{cvsignore}.
log calls the
RCS utility rlog, which prints all available information
about the RCS history file. This includes the location of the RCS
file, the head revision (the latest revision on the trunk),
all symbolic names (tags) and some other things. For each revision,
the revision number, the author, the number of lines added/deleted and
the log message are printed. All times are displayed in Coordinated
Universal Time (UTC). (Other parts of CVS print times in the local
timezone).
rlog:
-l
rlog prints all information that is
available. All other options (including those that normally have
other meanings) are passed through to rlog and restrict
the output. See rlog(1) for a complete description of options. This
incomplete list (which is a slightly edited extract from rlog(1))
lists all options that are useful in conjunction with CVS.
Please note: There can be no space between the
option and its argument, since rlog parses its options
in a different way than CVS.
-b
-ddates
d1<d2
x d2>d1
<d
x d>
d<
x >d
d
-h
-R
-rrevisions
rev1:rev2
:rev
rev:
branch
branch1:branch2
branch.
-sstates
-t
-wlogins
rlog prints the intersection of the revisions
selected with the options -d, -l,
-s, and -w, intersected with the union of
the revisions selected by -b and -r.
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.
rdiff
(@pxref{Common options}, for a complete description of them):
-D date
-f
-l
-Q
-q
-r tag
-c
-s
-t
-u
patch program can't
handle the unidiff format, so if you plan to post this patch to the
net you should probably not use -u.
-V vn
$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \ $$ Mail -s 'The patches you asked for' foo@@bar.comSuppose you have made release 1.3, and forked a branch called R_1_3fix for bugfixes. R_1_3_1 corresponds to release 1.3.1, which was made some time ago. Now, you want to see how much development has been done on the branch. This command can be used:
$ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name cvs rdiff: Diffing module-name File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6 File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4 File bar.h,v changed from revision 1.29.2.1 to 1.2
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 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.
release.
-Q
-q
-d
Warning: The release command uses
rm -r @file{module} to delete your file. This has the
very serious side-effect that any directory that you have created
inside your checked-out sources, and not added to the repository
(using the add command; @pxref{add}) will be silently
deleted---even if it is non-empty!
release releases your sources it will
print a one-line message for any file that is not up-to-date.
Warning: Any new directories that you have
created, but not added to the CVS directory hierarchy
with the add command (@pxref{add}) will be
silently ignored, even if they contain files.
U file
A file
R file
M file
? file
Note that no warning message like this is printed for spurious directories that CVS encounters. The directory, and all its contents, are silently ignored.
$ cd .. # You must stand immediately above the
# sources when you issue cvs release.
$ cvs release -d tc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) module `tc: y
$
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
@file{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 the actual files that you wish removed.
remove.
-l
-R
$ cd test $ rm ?.c $ cvs remove cvs remove: Removing . cvs remove: scheduling a.c for removal cvs remove: scheduling b.c for removal cvs remove: use 'CVS commit' to remove these files permanently $ cvs ci -m "Removed unneeded files" cvs commit: Examining . cvs commit: Committing .If you change your mind you can easily resurrect the file before you commit it, using the
add
command.
$ ls CVS ja.h oj.c $ rm oj.c $ cvs remove oj.c cvs remove: scheduling oj.c for removal cvs remove: use 'CVS commit' to remove this file permanently $ cvs add oj.c U oj.c cvs add: oj.c, version 1.1.1.1, resurrectedIf you realise your mistake before you run the
remove command you can use update to
resurrect the file:
$ rm oj.c $ cvs update oj.c cvs update: warning: oj.c was lost U oj.c
rtag works directly on the repository contents (and
requires no prior checkout). Use tag instead
(@pxref{tag}), to base the selection of revisions on the contents of
your working directory.
rtag
(@pxref{Common options}, for a complete description of them):
-D date
-f
-l
-n
-Q
-q
-R
-r tag
-a
rtag look in
the @file{Attic} (@pxref{Removing files}) 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).
-b
-d
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, or if you mis-tagged a module).
You can also use this command to anticipate the potential
impact of a cvs update on your working source
directory---but remember that things might change in the repository
before you run update.
status
(@pxref{Common options}, for a complete description of them):
-l
-R
-Q
-v
rtag, but the
versions are supplied implicitly by the CVS records of your working
files' history rather than applied explicitly. 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 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.
This command can also be used to delete a symbolic tag, or to create a branch. See the options section below.
tag
(@pxref{Common options}, for a complete description of them):
-l
-R
-Q
-q
-b
-d
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.
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
(@pxref{Common options}, for a complete description of them):
-D date
-f
-k kflag
status command can be viewed
to see the sticky options. cf. status.
-l
-P
-p
-Q
-q
-R
-r tag
update.
-A
-d
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.
-I name
update ignores files whose names match any
of the following:
RCSLOG RCS SCCS
CVS* cvslog.*
tags TAGS
.make.state .nse_depinfo
*~ #* .#* ,*
*.old *.bak *.BAK *.orig *.rej .del-*
*.a *.o *.so *.Z *.elc *.ln
core
Use -I ! to avoid ignoring any files at all.
@xref{cvsignore}, for other ways to make CVS ignore some files.
-jbranch
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; if the file @file{foo.c} is based on revision 1.6 and you want to remove the changes made between 1.3 and 1.5, you might do:
$ 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.
update keeps you informed of its progress by
printing a line for each file, prefaced with one character that
indicate the status of the file:
U file
A file
commit on the file. This is a reminder to you that the
file needs to be committed.
R file
commit on the file. This is a reminder to you that the
file needs to be committed.
M file
M can indicate one of two states for a file you're working on: either there were no modifications to the same file in the repository, so that your file remains as you last saw it; or there were modifications in the repository as well as in your copy, but they were merged successfully, without conflict, in your working directory.
CVS will print some messages if it merges your work, and a
backup copy of your working file (as it looked before you ran
update) will be made. The exact name of that file is
printed while update runs.
C file
? file
Note that no warning message like this is printed for spurious directories that CVS encounters. The directory, and all its contents, are silently ignored.
$ cvs -n -q update