import [_options] repository vendortag

releasetag ...

Use cvs import to incorporate an entire source distribution from an outside source (for example, a source vendor) into your source repository directory. You can use this command both for initial creation of a repository, and for wholesale updates to the module form the outside source.

The repository argument gives a directory name (or a path to a directory) under the CVS root directory for repositories; if the directory did not exist, import creates it.

When you use import for updates to source that has been modified in your source repository (since a prior import), it will notify you of any files that conflict in the two branches of development; use cvs checkout -j to reconcile the differences, as import instructs you to do.

By default, certain filenames are ignored during cvs import: names associated with CVS administration, or with other common source control systems; common names for patch files, object files, archive files, and editor backup files; and other names that are usually artifacts of assorted utilities. Currently, the default list of ignored files includes files matching these names:

RCSLOG RCS SCCS



CVS* cvslog.*



tags TAGS



.make.state .nse_depinfo



~ #* .#* ,



.old *.bak *.BAK *.orig *.rej .del_*



.a *.o *.so *.Z *.elc *.ln core

The outside source is saved in a first-level RCS branch, by default 1.1.1. Updates are leaves of this branch; for example, files from the first imported collection of source will be revision 1.1.1.1, then files from the first imported update will be revision 1.1.1.2, and so on.

At least three arguments are required. repository is needed to identify the collection of source. vendortag is a tag for the entire branch (for example, for 1.1.1). You must also specify at least one releasetag to identify the files at the leaves created each time you execute cvs import.

One of the standard cvs command options is available: _m message. If you do not specify a logging message with _m, your editor is invoked (as with commit) to allow you to enter one.

There are three additional special options.

Use _d to specify that each file's time of last modification should be used for the checkin date and time.

Use _b branch to specify a first-level branch other than 1.1.1.

Use _I name to specify filenames that should be ignored during import. You can use this option repeatedly. To avoid ignoring any files at all (even those ignored by default), specify _I !.

log [_l] rlog-options [files...]

Display log information for files. cvs log calls the RCS utility rlog; all the options described in rlog(1) are available. Among the more useful rlog options are _h to display only the header (including tag definitions, but omitting most of the full log); -r to select logs on particular revisions or ranges of revisions; and _d to select particular dates or date ranges. See rlog(1) for full explanations. This command is recursive by default, unless the _l option is specified.

rdiff [_flags][_V vn][_r t|_D d [_r t2|_D

d2]] modules...

Builds a Larry Wall format patch(1) file between two releases that can be fed directly into the patch program to bring an old release up-to-date with the new release. (This is one of the few cvs commands that operates directly from the repository and doesn't require a prior checkout.) The diff output is sent to the standard output device. You can specify (using the standard -r and _D options) any combination of one or two revisions or dates. If only one revision or date is specified, the patch file reflects differences between that revision or date and the current head revisions in the RCS file.

Note that if the software release affected is contained in more than one directory, then it may be necessary to specify the _p option to the patch command when patching the old sources, so that patch is able to find the files that are located in other directories.

If you use the option _V vn, RCS keywords are expanded according to the rules current in RCS version vn (the expansion format changed with RCS version 5).

The standard option flags _f and _l are available with this command. There are also several special options flags.

If you use the _s option, no patch output is produced. Instead, a summary of the changed or added files between the two releases is sent to the standard output device. This is useful for finding out, for example, which files have changed between two dates or revisions.

If you use the _t option, a diff of the top two revisions is sent to the standard output device. This is most useful for seeing what the last change to a file was.

If you use the _u option, the patch output uses the newer unidiff format for context diffs.

You can use _c to explicitly specify the diff _c form of context diffs (which is the default), if you like.

release [_dQq] modules...

This command is meant to safely cancel the effect of cvs checkout. Since cvs doesn't lock files, it isn't strictly necessary to use this command. You can always simply delete your working directory, if you like; but you risk losing changes you may have forgotten, and you leave no trace in the cvs history file that you've abandoned your checkout.

Use cvs release to avoid these problems. This command checks that no uncommitted changes are present; that you are executing it from immediately above, or inside, a cvs working directory; and that the repository recorded for your files is the same as the repository defined in the module database.

If all these conditions are true, cvs release leaves a record of its execution (attesting to your intentionally abandoning your checkout) in the cvs history log.

You can use the _d flag to request that your working copies of the source files be deleted if the release succeeds.

remove [_lR][files...]

Use this command to declare that you wish to remove files from the source repository. Like most cvs commands, cvs remove works on files in your working directory, not directly on the repository. As a safeguard, it also requires that you first erase the specified files from your working directory.

The files are not actually removed until you apply your changes to the repository with commit; at that point, the corresponding RCS files in the source repository are moved into the Attic directory (also within the source repository).