Synopsis: checkout [options] modules...
Changes: working directory.
Synonyms: co, get
Create or update a working directory containing copies of the
source files specified by
modules. You must execute
checkout before using most of the other cvsnt
commands, since most of them operate on your working directory.
modules 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. the section called “The modules file”.
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 global option).
The files created by checkout are created read-write, unless the -r option to cvsnt (the section called “Global options”) is specified, the CVSREAD environment variable is specified (Appendix C, All environment variables which affect CVS), or a watch is in effect for that file (the section called “Mechanisms to track who is editing files”).
Note that running checkout on a directory that was already built by a prior checkout is also permitted. This is similar to specifying the -d option to the update command in the sense that new directories that have been created in the repository will appear in your work area. However, checkout takes a module name whereas update takes a directory name. Also to use checkout this way it must be run from the top level directory (where you originally ran checkout from), so before you run checkout to update an existing directory, don't forget to change your directory to the top level directory.
For the output produced by the checkout command see the section called “update output”.
These standard options are supported by checkout (the section called “Common command options”, for a complete description of them):
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
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.
Do not run any checkout program (as specified with the -o option in the modules file; the section called “The modules file”).
Prune empty directories. See the section called “Moving and renaming directories”.
Pipe files to the standard output.
Checkout directories recursively. This option is on by default.
tag. This option is
sticky, and implies -P. See the section called “Sticky tags”, for more information on sticky
In addition to those, you can use these special command options with checkout:
Reset any sticky tags, dates, or -k options. See the section called “Sticky tags”, for more information on sticky tags/dates.
Copy the module file, sorted, to the standard output, instead of creating or modifying any files or directories in your working directory.
Create a directory called
dir for the
working files, instead of using the module name. In general,
using this flag is equivalent to using mkdir
followed by the checkout command without the
There is an important exception, however. It is very convenient when checking out a single item to have the output appear in a directory that doesn't contain empty intermediate directories. In this case only, cvsnt tries to "shorten" pathnames to avoid those empty directories.
For example, given a module foo that contains the file bar.c, the command cvs co -d dir foo will create directory dir and place bar.c inside. Similarly, given a module bar which has subdirectory baz wherein there is a file quux.c, the command cvs -d dir co bar/baz will create directory dir and place quux.c inside.
Using the -N flag will defeat this behavior. Given the same module definitions above, cvs co -N -d dir foo will create directories dir/foo and place bar.c inside, while cvs co -N -d dir bar/baz will create directories dir/bar/baz and place quux.c inside.
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.
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:
Perform the -j merge from the branchpoint not the last mergepoint. This can be useful to re-merge changes that have been merged before, however it likely to produce a lot of conflicts.
Perform the -j merge from the last recorded mergepoint. This is the default.
Only useful together with -d
dir. With this option, cvsnt will
not "shorten" module paths in your working directory when you
check out a single module. See the -d flag
for examples and a discussion.
Like -c, but include the status of all modules, and sort it by the status string. the section called “The modules file”, for info about the -s option that is used inside the modules file to set the module status.
Produce 3-way conflict differences, containing the old and new files from the server and the edited files.
Select between conflicting case-sensitive names on a case-insensitive client. This provides limited support for checking out repositories with such conflicts - the problem should really be fixed in the repository.
Update using the last checkin time not the current time. This can cause issues with build systems so it is not recommended that this be used unless you are fully aware of the side-effects.