checkout--Check out sources for editing

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.

The 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”.

checkout options

These standard options are supported by checkout (the section called “Common command options”, for a complete description of them):

-D date

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

-k kflag

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.


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.

-r tag

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

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.

-d dir

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 dir; cd dir followed by the checkout command without the -d flag.

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.

-j tag

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

Chapter 6, Branching and merging.


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.

checkout examples

Get a copy of the module tc:

$ cvs checkout tc

Get a copy of the module tc as it looked one day ago:

$ cvs checkout -D yesterday tc