the _m option, thus suppressing the editor invocation, or use the _F option to specify that the argument file contains the log message.

The -r option can be used to commit to a particular symbolic or numeric revision within the RCS file. For example, to bring all your files up to the RCS revision 3.0 (including those that haven't changed), you might use

example% cvs commit -r3.0

cvs will only allow you to commit to a revision that is on the main trunk (a revision with a single dot). However, you can also commit to a branch revision (one that has an even number of dots) with the -r option. To create a branch revision, one typically use the _b option of the rtag or tag commands. Then, either checkout or update can be used to base your sources on the newly created branch. From that point on, all commit changes made within these working sources will be automatically added to a branch revision, thereby not perturbing mainline development in any way. For example, if you had to create a patch to the 1.2 version of the product, even though the 2.0 version is already under development, you might use this:

example% cvs rtag -b -rFCS1_2 FCS1_2 Patch product_module

example% cvs checkout -rFCS1_2_Patch product module

example% cd product module

[[ hack away ]]

example% cvs commit

Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your group would like to work on this software with you, but without disturbing mainline development, you could commit your change to a new branch. Others can then check out your experimental stuff and utilize the full benefit of cvs conflict resolution. The scenario might look like this:

example% cvs tag -b EXPR1

example% cvs update -rEXPR1

[[ hack away ]]

example% cvs commit

Others would simply do cvs checkout -rEXPR1 whatever_module to work with you on the experimental change.

diff [_kl][rcsdiff_options][[-r rev1 | _D

date1][-r rev2 | _D date2]] [files...]

You can compare your working files with revisions in the source repository, with the cvs diff command. If you don't specify a particular revision, your files are compared with the revisions they were based on. You can also use the standard cvs command option -r to specify a particular revision to compare your files with. Finally, if you use -r twice, you can see differences between two revisions in the repository. You can also specify _D options to diff against a revision in the past. The -r and _D options can be mixed together with at most two options ever specified.

See rcsdiff(1) for a list of other accepted options.

If you don't specify any files, diff will display differences for all those files in the current directory (and its subdirectories, unless you use the standard option _l) that differ from the corresponding revision in the source repository (that is, files that you have changed), or that differ from the revision specified.

export [_f lNnQq] -r rev | _D date [_d

dir][_k kflag] module...

This command is a variant of cvs checkout; use it when you want a copy of the source for module without the cvs administrative directories. For example, you might use cvs export to prepare source for shipment off-site. This command requires that you specify a date or tag (with _D or -r), so that you can count on reproducing the source you ship to others.

The only nonstandard options are _d dir (write the source into directory dir) and _N (don't shorten module paths). These have the same meanings as the same options in cvs checkout.

The _kv option is useful when export is used. This causes any RCS keywords to be expanded such that an import done at some other site will not lose the keyword revision information. Other kflag options may be used with cvs export and are described in co(1).

history [-report][_flags][_options

args][files...]

cvs keeps a history file that tracks each use of the checkout, commit, rtag, update, and release commands. You can use cvs history to display this information in various formats.

Several options (shown as [_report] in the preceding bulleted code line) control what kind of report is generated:

The options shown as _flags constrain the report without requiring option arguments:

The options shown as _options args constrain the report based on an argument: