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 the file).

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 kflag. See Chapter 13, Keyword substitution. This option is sticky; future updates of this file in this working directory will use the same kflag. The 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.

Retrieve revision/tag rev. This option is sticky, and implies -P. See the section called “Sticky tags”, for more information on sticky tags/dates.

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 .#file.revision, however).

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 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. 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 -j 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: -jSymbolic_Tag:Date_Specifier.

Chapter 6, Branching and merging.

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 changes to file with changes from the source repository. 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 .#file.revision where 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”).