-->
Page 95
_l | Local; run only in current working directory, rather than recurring through subdirectories. Available with the following commands: checkout, commit, diff, export, remove, rdiff, rtag, status, tag, and update. |
WARNING |
This is not the same as the overall cvs _l option, which you can specify to the left of a cvs command. |
_n | Do not run any checkout/commit/tag/update program. (A program can be specified to run on each of these activities, in the modules database; this option bypasses it.) Available with the checkout, commit, export, and rtag commands. |
WARNING |
This is not the same as the overall cvs _n option, which you can specify to the left of a cvs command. |
_P | Prune (remove) directories that are empty after being updated, on checkout, or update. Normally, an empty directory (one that is void of revision-controlled files) is left alone. Specifying _P will cause these directories to be silently removed from your checked-out sources. This does not remove the directory from the repository, only from your checked out copy. Note that this option is implied by the -r or _D options of checkout and export. |
_p | Pipe the files retrieved from the repository to standard output, rather than writing them in the current directory. Available with the checkout and update commands. |
-r tag | Use the revision specified by the tag argument instead of the default head revision. As well as arbitrary tags defined with the tag or rtag command, two special tags are always available: HEAD refers to the most recent version available in the repository, and BASE refers to the revision you last checked out into the current working directory. The tag specification is "sticky" when you use this option with cvs checkout or cvs update to make your own copy of a file: cvs remembers the tag and continues to use it on future update commands, until you specify otherwise. tag can be either a symbolic or numeric tag, in RCS fashion. Specifying the _q global option along with the -r command option is often useful, to suppress the warning messages when the RCS file does not contain the specified tag. -r is available with the checkout, commit, diff, history, export, rdiff, rtag, and update commands. |
WARNING |
This is not the same as the overall cvs -r option, which you can specify to the left of a cvs command. |
cvs COMMANDS
Here (finally) are details on all the cvs commands and the options each accepts. The summary lines at the top of each command's description highlight three kinds of things:
Command Options and Arguments | Special options are described in detail; common command options may appear only in the summary line. |
Working Directory, or Repository? | Some cvs commands require a working directory to operate; some require a repository. Also, some commands change the repository, some change the working directory, and some change nothing. |
Synonyms | Many commands have synonyms, which you may find easier to remember (or type) than the principal name. |
Page 96
add [_k kflag][_m `message'] files...
Requires: | Repository, working directory |
Changes: | Working directory |
Synonym: | new |
Use the add command to create a new file or directory in the RCS source repository. The files or directories specified with add must already exist in the current directory (which must have been created with the checkout command). To add a whole new directory hierarchy to the source repository (for example, files received from a third-party vendor), use the cvs import command instead.
If the argument to cvs add refers to an immediate subdirectory, the directory is created at the correct place in the RCS source repository, and the necessary cvs administration files are created in your working directory. If the directory already exists in the source repository, cvs add still creates the administration files in your version of the directory. This allows you to use cvs add to add a particular directory to your private sources even if someone else created that directory after your checkout of the sources. You can do the following:
example% mkdir new_directory example% cvs add new_directory example% cvs update new_directory
An alternate approach using cvs update might be:
example% cvs update -d new_directory
(To add any available new directories to your working directory, it's probably simpler to use cvs checkout or cvs update -d.)
The added files are not placed in the RCS source repository until you use cvs commit to make the change permanent. Doing a cvs add on a file that was removed with the cvs remove command will resurrect the file, if no cvs commit command intervened.
You will have the opportunity to specify a logging message, as usual, when you use cvs commit to make the new file permanent. If you'd like to have another logging message associated with just creation of the file (for example, to describe the file's purpose), you can specify it with the _m message option to the add command.
The -k kflag option specifies the default way that this file will be checked out. The kflag argument is stored in the RCS file and can be changed with cvs admin. Specifying -ko is useful for checking in binaries that shouldn't have the RCS id strings expanded.
admin [rcs-options] files...
Requires: | Repository, working directory |
Changes: | Repository |
Synonym: | rcs |
This is the cvs interface to assorted administrative RCS facilities, documented in rcs(1). cvs admin simply passes all its options and arguments to the rcs command; it does no filtering or other processing. This command does work recursively, however, so extreme care should be used.
checkout [options] modules...
Requires: | Repository |
Changes: | Working directory |
Synonyms: | co, get |
Make a working directory containing copies of the source files specified by modules. You must execute cvs checkout before using most of the other cvs commands, since most of them operate on your working directory.
modules are either symbolic names [themselves defined as the module modules in the source repository; see cvs(5)] for some collection of source directories and files, or paths to directories or files in the repository.
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