update

Synopsis: update [OPTIONS] [FILES]

• Alternate names – up, upd
• Requires – Working copy, repository
• Changes – Working copy

Merges changes from the repository into your working copy. As a side effect, it indicates which files in your working copy are modified (but if the -Q global option is passed, these indications won't be printed). (See also checkout.)

Options:

• -A – Clears any sticky tags, sticky dates, or sticky RCS keyword expansion modes. This may result in the contents of files changing, if the trunk-head revisions are different from the former sticky revisions. (Think of -A as being like a fresh checkout of the project trunk.)
• -C – Clean out any locally changed files and replace them with the latest versions from the repository. This is not necessarily the same as reverting the files, since the repository may have changed since the last update or checkout. Any local modifications are saved in .#file.rev.

  Note: this option was implemented in January 2000; if your CVS was acquired before then, you'd have to upgrade.

• -D DATE – Updates to the most recent revisions no later than DATE. This option is sticky and implies -P. If the working copy has a sticky date, commits are not possible.
• -d – Retrieves absent directories – that is, directories that exist in the repository but not yet in the working copy. Such directories may have been created in the repository after the working copy was checked out. Without this option, update only operates on the directories present in the working copy; new files are brought down from the repository, but new directories are not. (See also -P.)
• -f – Forces to head revision if no matching revision is found with the -D or -r flags.
• -I NAME – Like the -I option of import.
• -j REV[:DATE] or -j REV1[:DATE] -j REV2[:DATE] – Joins, or merges, two lines of development. Ignoring the optional DATE arguments for the moment (we'll get to them later), here's how -j works: If only one -j is given, it takes all changes from the common ancestor to REV and merges them into the working copy. The common ancestor is the latest revision that is ancestral to both the revisions in the working directory and to REV. If two -j options are given, it merges the changes from REV1 to REV2 into the working copy.

  The special tags HEAD and BASE may be used as arguments to -j; they mean the most recent revision in the repository, and the revision on which the current working copy file is based, respectively.

  As for the optional DATE arguments, if REV is a branch, it is normally taken to mean the latest revision on that branch, but you can restrict it to the latest revision no later than DATE. The date should be separated from the revision by a colon, with no spaces, for instance:

            floss$ cvs update -j ABranch:1999-07-01 -j ABranch:1999-08-01
       

  In this example, different dates on the same branch are used, so the effect is to take the changes on that branch from July to August and merge them into the working copy. However, note that there is no requirement that the branch be the same in both -j options.

• -k MODE – Does RCS keyword substitution according to MODE. (See the section Keyword Substitution (RCS Keywords) later in this chapter.) The mode remains sticky on the working copy, so it will affect future updates (but see -A).
• -l – Local. Updates the current directory only.
• -P – Prunes empty directories. Any CVS-controlled directory that contains no files at the end of the update are removed from the working copy. (See also -d.)
• -p – Sends file contents to standard output instead of to the files. Used mainly for reverting to a previous revision without producing sticky tags in the working copy. For example:

            floss$ cvs update -p -r 1.3 README.txt > README.txt
       

  Now README.txt in the working copy has the contents of its past Revision 1.3, just as if you had hand-edited it into that state.

• -R – Recursive. Descends into subdirectories to update (the default). The only reason you'd specify it is to counteract a -l in .cvsrc.
• -r REV – Updates (or downdates, or crossdates) to revision REV. When updating a whole working copy, REV is most often a tag (regular or branch). However, when updating an individual file, it is just as likely to be a revision number as a tag.

  This option is sticky. If the files are switched to a nonbranch tag or sticky revision, they cannot be committed until the stickiness is removed. (See -A.) If REV was a branch tag, however, commits are possible. They'll simply commit new revisions on that branch.

• -WSPEC – Specifies wrapper-style filters to use during the update. You can use this option multiple times. (See cvswrappers in Repository Administrative Files in this chapter for details about wrapper specs.) There is no space between -W and its argument.