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.
It is unwise to let your local working directory become out of sync with others for too long. Depending on your working model it may be necessary to run updates daily or even hourly to keep in step. On the other hand if you are the only developer on a project it may not be necessary to update at all.
If updating is left too long, then conflicts that arise get progressively harder to fix over time as the code diverges. On the other hand frequent updating may mean that there are no conflicts to deal with at all.
These standard options are available with update (the section called “Common command options”, for a complete description of them):
Automatically edit modified/merged files.
Automatically edit modified/merged files and unmodified files.
Use the most recent revision no later than
date. This option is sticky, and implies
-P. See the section called “Sticky tags”, for
more information on sticky tags/dates.
Only useful with the -D
date or -r
tag flags. If no matching revision
is found, retrieve the most recent revision (instead of ignoring
Write clean repository copy to this filename. This is most often
used when you need to perfom a visual side-by-side diff - for which you
need two complete copies of the file, but where the 'name' of the file
for that point in time may not be known. ie: you haVe the file with
filename 'blat.htm' in your current directory and
you want to compare it to the HEAD revision: but at HEAD it may have
a different name (someone has used the rename
command). You can use the diff without knowing
the revisions filename, but you can't use the checkout
unless you know the actual filename for that point in time. So this
is the situation where this flag of the udpate command can be used.
Process keywords according to
See Chapter 13, Keyword substitution. This option is
sticky; future updates of this file in this working directory
will use the same
status command can be viewed to see the
sticky options. See the section called “status--Display the state of a file in the working
directory”, for more
information on the status command.
Local; run only in current working directory. Chapter 7, Recursive behavior.
Prune empty directories. See the section called “Moving and renaming directories”.
Pipe files to the standard output.
Update directories recursively (default). Chapter 7, Recursive behavior.
rev. This option
is sticky, and implies -P. See the section called “Sticky tags”, for more information on sticky
These special options are also available with update.
Provide 3-way conflicts.
Reset any sticky tags, dates, or -k options. See the section called “Sticky tags”, for more information on sticky tags/dates.
Set the boundary of a -j merge to revisions marked with a particular bug. This is used to extract individual bug fixes from one branch to another.
If there are other revisions unrelated to the bug required to merge all the differences, these will also be merged. This option is much more useful in quiet or controlled repositories where this happens infrequently.
Perform the -j merge from the branchpoint, ignoring mergepoints.
Overwrite locally modified files with clean copies from
the repository (the modified file is saved in
If the file is edited, update the base revision copy to the latest revision. If this option is not used an unedit will always revert to the same revision that is edited, not the latest revision in the repository.
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.
Ignore files whose names match
your working directory) during the update. You can specify
-I more than once on the command line to
specify several files to ignore. Use -I ! to
avoid ignoring any files at all. the section called “Ignoring files via cvsignore”,
for other ways to make cvsnt ignore some files.
Perform the -j merge based on the last mergepoint. This is the default.
Perform limited selection between conflicting case sensitive names on a case insensitive system. This option can be used to checkout files with conflicting names however it is not a solution to the problem - the conflict should be fixed in the repository.
Update using the last checkin time of the file not the current time. Do not use this option if you are using a makefile based system as it will cause problems with the build process. On other systems be aware of any side effects before using this option.
Specify file names that should be filtered during update.
You can use this option repeatedly. Use -W !
avoid using the default wrappers.
spec can be
a file name pattern of the same type that you can specify in the
.cvswrappers file. the section called “The cvswrappers file”.
With two -j options, merge changes from the revision specified with the first -j option to the revision specified with the second j option, into the working directory.
With one -j option, merge changes from the ancestor revision to the revision specified with the -j option, into the working directory. The ancestor revision is the common ancestor of the revision which the working directory is based on, and the revision specified in the -j option.
Note that using a single -j
tagname option rather than
branchname to merge
changes from a branch will often not remove files which were
removed on the branch. the section called “Merging can add or remove files”, for more.
In addition, each -j option can contain
an 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:
update and checkout keep you informed of their progress by printing a line for each file, preceded by one character indicating the status of the file:
The file was brought up to date with respect to the repository. This is done for any file that exists in the repository but not in your source, and for files that you haven't changed but are not the most recent versions available in the repository.
Like U, but the cvsnt server sends a patch instead of an entire file. These two things accomplish the same thing.
The file has been added to your private copy of the sources, and will be added to the source repository when you run commit on the file. This is a reminder to you that the file needs to be committed.
The file has been removed from your private copy of the sources, and will be removed from the source repository when you run commit on the file. This is a reminder to you that the file needs to be committed.
The file is modified in your working directory.
M can indicate one of two states for a file you're working on: either there were no modifications to the same file in the repository, so that your file remains as you last saw it; or there were modifications in the repository as well as in your copy, but they were merged successfully, without conflict, in your working directory.
cvsnt 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.
A conflict was detected while trying to merge your
file with changes from the source
file (the copy in your working
directory) is now the result of attempting to merge the two
revisions; an unmodified copy of your file is also in your
working directory, with the name
revision is the revision that your
modified file started from. Resolve the conflict as described in
the section called “Conflicts example”. (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.) Under vms, the file name starts with
__ rather than .#.
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 cvsnt to ignore (see the
description of the -I option, and the section called “Ignoring files via cvsignore”).