Manual Pages for UNIX Darwin command on man ocvs

OCVS(1) OCVS(1)

NAME

ocvs - Concurrent Versions System

SYNOPSIS

ccvvss [ cvsoptions ] cvscommand [ commandoptions ] [ commandargs ] NNOOTTEE

The command ocvs is recommended for legacy use only where tar wrappers

are being used. References to cvs in this manpage refer to the legacy

ocvs command.

This manpage is a summary of some of the features of ccvvss but for more

in-depth documentation, consult the Cederqvist manual (as described in

the SEE ALSO section of this manpage).

DESCRIPTION

CVS is a version control system, which allows you to keep old versions of files (usually source code), keep a log of who, when, and why changes occurred, etc., like RCS or SCCS. Unlike the simpler systems, CVS does not just operate on one file at a time or one directory at a

time, but operates on hierarchical collections of directories consist-

ing of version controlled files. CVS helps to manage releases and to control the concurrent editing of source files among multiple authors. CVS allows triggers to enable/log/control various operations and works well over a wide area network. ccvvss keeps a single copy of the master sources. This copy is called the source ``repository''; it contains all the information to permit extracting previous software releases at any time based on either a symbolic revision tag, or a date in the past. EESSSSEENNTTIIAALL CCOOMMMMAANNDDSS ccvvss provides a rich variety of commands (cvscommand in the Synopsis), each of which often has a wealth of options, to satisfy the many needs of source management in distributed environments. However, you don't have to master every detail to do useful work with ccvvss; in fact, five

commands are sufficient to use (and contribute to) the source reposi-

tory. ccvvss cchheecckkoouutt modules... A necessary preliminary for most ccvvss work: creates your private copy of the source for modules (named collections of source; you can also use a path relative to the source repository here). You can work with this copy without interfering with others' work. At least one subdirectory level is always created. ccvvss uuppddaattee Execute this command from within your private source directory when you wish to update your copies of source files from changes that other developers have made to the source in the repository. ccvvss aadddd file... Use this command to enroll new files in ccvvss records of your working directory. The files will be added to the repository the next time you run `ccvvss ccoommmmiitt'. Note: You should use the `ccvvss iimmppoorrtt' command to bootstrap new sources into the source repository. `ccvvss aadddd' is only used for new files to an already

checked-out module.

ccvvss rreemmoovvee file... Use this command (after erasing any files listed) to declare that you wish to eliminate files from the repository. The removal does not affect others until you run `ccvvss ccoommmmiitt'. ccvvss ccoommmmiitt file... Use this command when you wish to ``publish'' your changes to

other developers, by incorporating them in the source reposi-

tory. OOPPTTIIOONNSS

The ccvvss command line can include cvsoptions, which apply to the over-

all ccvvss program; a cvscommand, which specifies a particular action on the source repository; and commandoptions and commandarguments to fully specify what the cvscommand will do.

Warning: you must be careful of precisely where you place options rela-

tive to the cvscommand. The same option can mean different things depending on whether it is in the cvsoptions position (to the left of a ccvvss command) or in the commandoptions position (to the right of a ccvvss command).

There are only two situations where you may omit cvscommand: `ccvvss -HH'

or `ccvvss --hheellpp' elicits a list of available commands, and `ccvvss -vv' or

`ccvvss --vveerrssiioonn' displays version information on ccvvss itself.

CCVVSS OOPPTTIIOONNSS As of release 1.6, ccvvss supports GNU style long options as well as short options. Only a few long options are currently supported, these are

listed in brackets after the short options whose functions they dupli-

cate. Use these options to control the overall ccvvss program:

-HH [[ --hheellpp ]]

Display usage information about the specified cvscommand (but do not actually execute the command). If you don't specify a

command name, `ccvvss -HH' displays a summary of all the commands

available.

-QQ Causes the command to be really quiet; the command will generate

output only for serious problems.

-qq Causes the command to be somewhat quiet; informational messages,

such as reports of recursion through subdirectories, are sup-

pressed.

-bb bindir

Use bindir as the directory where RCS programs are located (CVS 1.9 and older). Overrides the setting of the RCSBIN environment

variable. This value should be specified as an absolute path-

name.

-dd CVSrootdirectory

Use CVSrootdirectory as the root directory pathname of the master source repository. Overrides the setting of the CVSROOT environment variable. This value should be specified as an absolute pathname.

-ee editor

Use editor to enter revision log information. Overrides the setting of the CVSEDITOR and the EDITOR environment variables.

-ff Do not read the ccvvss startup file (~/.cvsrc).

-ll Do not log the cvscommand in the command history (but execute

it anyway). See the description of the hhiissttoorryy command for information on command history.

-nn Do not change any files. Attempt to execute the cvscommand,

but only to issue reports; do not remove, update, or merge any existing files, or create any new files.

-tt Trace program execution; display messages showing the steps of

ccvvss activity. Particularly useful with -nn to explore the poten-

tial impact of an unfamiliar command.

-rr Makes new working files read-only. Same effect as if the CVS-

READ environment variable is set.

-RR Turns on read-only repository mode. This allows one to check

out from a read-only repository, such as within an anoncvs

server, or from a CDROM repository. Same effect as if the CVS-

READONLYFS environment variable is set. Using -RR can also con-

siderably speed up checkout's over NFS.

-vv [[ --vveerrssiioonn ]]

Displays version and copyright information for ccvvss.

-ww Makes new working files read-write (default). Overrides the

setting of the CVSREAD environment variable.

-xx Encrypt all communication between the client and the server. As

of this writing, this is only implemented when using a Kerberos connection.

-zz compression-level

When transferring files across the network use ggzziipp with com-

pression level compression-level to compress and de-compress

data as it is transferred. Requires the presence of the GNU ggzziipp program in the current search path at both ends of the link. UUSSAAGGEE

Except when requesting general help with `ccvvss -HH', you must specify a

cvscommand to ccvvss to select a specific release control function to perform. Each ccvvss command accepts its own collection of options and

arguments. However, many options are available across several com-

mands. You can display a usage summary for each command by specifying

the -HH option with the command.

CCVVSS SSTTAARRTTUUPP FFIILLEE Normally, when CVS starts up, it reads the .cvsrc file from the home directory of the user reading it. This startup procedure can be turned

off with the -ff flag.

The .cvsrc file lists CVS commands with a list of arguments, one com-

mand per line. For example, the following line in .cvsrc:

diff -c

will mean that the `ccvvss ddiiffff' command will always be passed the -c

option in addition to any other options that are specified in the com-

mand line (in this case it will have the effect of producing context sensitive diffs for all executions of `ccvvss ddiiffff' ). CCVVSS CCOOMMMMAANNDD SSUUMMMMAARRYY Here are brief descriptions of all the ccvvss commands: aadddd Add a new file or directory to the repository, pending a `ccvvss ccoommmmiitt' on the same file. Can only be done from within sources created by a previous `ccvvss cchheecckkoouutt' invocation. Use `ccvvss

iimmppoorrtt' to place whole new hierarchies of sources under ccvvss con-

trol. (Does not directly affect repository; changes working directory.) aaddmmiinn Execute control functions on the source repository. (Changes repository directly; uses working directory without changing it.) cchheecckkoouutt Make a working directory of source files for editing. (Creates or changes working directory.) ccoommmmiitt Apply to the source repository changes, additions, and deletions from your working directory. (Changes repository.) ddiiffff Show differences between files in working directory and source repository, or between two revisions in source repository. (Does not change either repository or working directory.) eexxppoorrtt Prepare copies of a set of source files for shipment off site.

Differs from `ccvvss cchheecckkoouutt' in that no ccvvss administrative direc-

tories are created (and therefore `ccvvss ccoommmmiitt' cannot be exe-

cuted from a directory prepared with `ccvvss eexxppoorrtt'), and a sym-

bolic tag must be specified. (Does not change repository; cre-

ates directory similar to working directories). hhiissttoorryy Show reports on ccvvss commands that you or others have executed on a particular file or directory in the source repository. (Does not change repository or working directory.) History logs are

kept only if enabled by creation of the `$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//hhiiss-

ttoorryy' file; see ccvvss(55).

iimmppoorrtt Incorporate a set of updates from off-site into the source

repository, as a ``vendor branch''. (Changes repository.) lloogg Display log information. (Does not change repository or working directory.) rrddiiffff Prepare a collection of diffs as a patch file between two releases in the repository. (Does not change repository or working directory.) rreelleeaassee Cancel a `ccvvss cchheecckkoouutt', abandoning any changes. (Can delete working directory; no effect on repository.) rreemmoovvee Remove files from the source repository, pending a `ccvvss ccoommmmiitt' on the same files. (Does not directly affect repository; changes working directory.) rrttaagg Explicitly specify a symbolic tag for particular revisions of files in the source repository. See also `ccvvss ttaagg'. (Changes

repository directly; does not require or affect working direc-

tory.) ssttaattuuss Show current status of files: latest version, version in working

directory, whether working version has been edited and, option-

ally, symbolic tags in the RCS file. (Does not change reposi-

tory or working directory.) ttaagg Specify a symbolic tag for files in the repository. By default, tags the revisions that were last synchronized with your working

directory. (Changes repository directly; uses working direc-

tory without changing it.) uuppddaattee Bring your working directory up to date with changes from the repository. Merges are performed automatically when possible; a

warning is issued if manual resolution is required for conflict-

ing changes. (Changes working directory; does not change repos-

itory.) CCOOMMMMOONN CCOOMMMMAANNDD OOPPTTIIOONNSS This section describes the commandoptions that are available across several ccvvss commands. Not all commands support all of these options;

each option is only supported for commands where it makes sense. How-

ever, when a command has one of these options you can count on the same meaning for the option as in other commands. (Other command options,

which are listed with the individual commands, may have different mean-

ings from one ccvvss command to another.) Warning: the hhiissttoorryy command is an exception; it supports many options that conflict even with these standard options.

-DD datespec

Use the most recent revision no later than datespec (a single argument, date description specifying a date in the past). A wide variety of date formats are supported, in particular ISO

("1972-09-24 20:05") or Internet ("24 Sep 1972 20:05"). The

datespec is interpreted as being in the local timezone, unless a specific timezone is specified. The specification is ``sticky'' when you use it to make a private copy of a source

file; that is, when you get a working file using -DD, ccvvss records

the date you specified, so that further updates in the same directory will use the same date (unless you explicitly override

it; see the description of the uuppddaattee command). -DD is available

with the cchheecckkoouutt, ddiiffff, hhiissttoorryy, eexxppoorrtt, rrddiiffff, rrttaagg, and uuppddaattee commands. Examples of valid date specifications include: 11 mmoonntthh aaggoo 22 hhoouurrss aaggoo 440000000000 sseeccoonnddss aaggoo llaasstt yyeeaarr llaasstt MMoonnddaayy yyeesstteerrddaayy aa ffoorrttnniigghhtt aaggoo 33//3311//9922 1100::0000::0077 PPSSTT JJaannuuaarryy 2233,, 11998877 1100::0055ppmm 2222::0000 GGMMTT

-ff When you specify a particular date or tag to ccvvss commands, they

normally ignore files that do not contain the tag (or did not

exist on the date) that you specified. Use the -ff option if you

want files retrieved even when there is no match for the tag or

date. (The most recent version is used in this situation.) -ff

is available with these commands: cchheecckkoouutt, eexxppoorrtt, rrddiiffff, rrttaagg, and uuppddaattee.

-HH Help; describe the options available for this command. This is

the only option supported for all ccvvss commands.

-kk kflag

Alter the default processing of keywords. The -kk option is

available with the aadddd, cchheecckkoouutt, ddiiffff, eexxppoorrtt, rrddiiffff, and uuppddaattee commands. Your kflag specification is ``sticky'' when you use it to create a private copy of a source file; that is, when you use this option with the cchheecckkoouutt or uuppddaattee commands, ccvvss associates your selected kflag with the file, and continues to use it with future uuppddaattee commands on the same file until you specify otherwise.

Some of the more useful kflags are -ko and -kb (for binary

files), and -kv which is useful for an eexxppoorrtt where you wish to

retain keyword information after an iimmppoorrtt at some other site.

-ll Local; run only in current working directory, rather than recur-

ring through subdirectories. Available with the following com-

mands: cchheecckkoouutt, ccoommmmiitt, ddiiffff, eexxppoorrtt, rreemmoovvee, rrddiiffff, rrttaagg, ssttaa-

ttuuss, ttaagg, and uuppddaattee. Warning: this is not the same as the

overall `ccvvss -ll' option, which you can specify to the left of a

ccvvss command!

-nn Do not run any cchheecckkoouutt/ccoommmmiitt/ttaagg/uuppddaattee program. (A program

can be specified to run on each of these activities, in the mod-

ules database; this option bypasses it.) Available with the cchheecckkoouutt, ccoommmmiitt, eexxppoorrtt, and rrttaagg commands. Warning: this is

not the same as the overall `ccvvss -nn' option, which you can spec-

ify to the left of a ccvvss command!

-PP Prune (remove) directories that are empty after being updated,

on cchheecckkoouutt, or uuppddaattee. Normally, an empty directory (one that

is void of revision-controlled files) is left alone. Specifying

-PP 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 -rr or -DD options of cchheecckkoouutt and

eexxppoorrtt.

-pp Pipe the files retrieved from the repository to standard output,

rather than writing them in the current directory. Available with the cchheecckkoouutt and uuppddaattee commands.

-rr tag Use the revision specified by the tag argument instead of the

default ``head'' revision. As well as arbitrary tags defined

with the ttaagg or rrttaagg command, two special tags are always avail-

able: `HHEEAADD' refers to the most recent version available in the repository, and `BBAASSEE' refers to the revision you last checked out into the current working directory. The tag specification is ``sticky'' when you use this option with `ccvvss cchheecckkoouutt' or `ccvvss uuppddaattee' to make your own copy of a file: ccvvss remembers the tag and continues to use it on future uuppddaattee commands, until you specify otherwise. tag can be either

a symbolic or numeric tag. Specifying the -qq global option

along with the -rr command option is often useful, to suppress

the warning messages when the RCS file does not contain the

specified tag. -rr is available with the cchheecckkoouutt, ccoommmmiitt, ddiiffff,

hhiissttoorryy, eexxppoorrtt, rrddiiffff, rrttaagg, and uuppddaattee commands. Warning:

this is not the same as the overall `ccvvss -rr' option, which you

can specify to the left of a ccvvss command! CCVVSS CCOOMMMMAANNDDSS Here (finally) are details on all the ccvvss 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 below; common command options may appear only in the summary line. Working Directory, or Repository? Some ccvvss 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.

aadddd [-kk kflag] [-mm ''message''] files...

Requires: repository, working directory. Changes: working directory. Synonym: nneeww Use the aadddd command to create a new file or directory in the source repository. The files or directories specified with aadddd must already exist in the current directory (which must have been created with the cchheecckkoouutt command). To add a whole new directory hierarchy to the source repository (for example, files

received from a third-party vendor), use the `ccvvss iimmppoorrtt' com-

mand instead.

If the argument to `ccvvss aadddd' refers to an immediate sub-direc-

tory, the directory is created at the correct place in the source repository, and the necessary ccvvss administration files are created in your working directory. If the directory already exists in the source repository, `ccvvss aadddd' still creates the administration files in your version of the directory. This allows you to use `ccvvss aadddd' to add a particular directory to your private sources even if someone else created that directory after your cchheecckkoouutt of the sources. You can do the following:

eexxaammppllee%% mmkkddiirr nneewwddiirreeccttoorryy

eexxaammppllee%% ccvvss aadddd nneewwddiirreeccttoorryy

eexxaammppllee%% ccvvss uuppddaattee nneewwddiirreeccttoorryy

An alternate approach using `ccvvss uuppddaattee' might be:

eexxaammppllee%% ccvvss uuppddaattee -dd nneewwddiirreeccttoorryy

(To add any available new directories to your working directory,

it's probably simpler to use `ccvvss cchheecckkoouutt' or `ccvvss uuppddaattee -dd'.)

The added files are not placed in the source repository until you use `ccvvss ccoommmmiitt' to make the change permanent. Doing a `ccvvss aadddd' on a file that was removed with the `ccvvss rreemmoovvee' command will resurrect the file, if no `ccvvss ccoommmmiitt' command intervened. You will have the opportunity to specify a logging message, as usual, when you use `ccvvss ccoommmmiitt' 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 `-mm message' option to the

aadddd command.

The `-kk kkffllaagg' option specifies the default way that this file

will be checked out. The `kkffllaagg' argument is stored in the RCS

file and can be changed with `ccvvss aaddmmiinn'. Specifying `-kkoo' is

useful for checking in binaries that shouldn't have keywords expanded.

aaddmmiinn [rcs-options] files...

Requires: repository, working directory. Changes: repository. Synonym: rrccss This is the ccvvss interface to assorted administrative facilities, similar to rrccss(11). This command works recursively, so extreme care should be used. cchheecckkoouutt [ooppttiioonnss] modules... Requires: repository. Changes: working directory. Synonyms: ccoo, ggeett Make a working directory containing copies of the source files specified by modules. You must execute `ccvvss cchheecckkoouutt' before using most of the other ccvvss commands, since most of them operate on your working directory. modules are either symbolic names (themselves defined as the module `mmoodduulleess' in the source repository; see ccvvss(55)) for some

collection of source directories and files, or paths to directo-

ries or files in the repository. Depending on the modules you specify, cchheecckkoouutt 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 repository.

Note that cchheecckkoouutt is used to create directories. The top-level

directory created is always added to the directory where cchheecckk-

oouutt is invoked, and usually has the same name as the specified

module. In the case of a module alias, the created sub-direc-

tory may have a different name, but you can be sure that it will

be a sub-directory, and that cchheecckkoouutt will show the relative

path leading to each file as it is extracted into your private

work area (unless you specify the -QQ global option).

Running `ccvvss cchheecckkoouutt' on a directory that was already built by a prior cchheecckkoouutt is also permitted, and has the same effect as

specifying the -dd option to the uuppddaattee command described below.

The options permitted with `ccvvss cchheecckkoouutt' include the standard

command options -PP, -ff, -kk kflag , -ll, -nn, -pp, -rr tag, and -DD

date. In addition to those, you can use these special command options with cchheecckkoouutt:

Use the -AA option to reset any sticky tags, dates, or -kk

options. (If you get a working file using one of the -rr, -DD, or

-kk options, ccvvss remembers the corresponding tag, date, or kflag

and continues using it on future updates; use the -AA option to

make ccvvss forget these specifications, and retrieve the ``head'' version of the file).

The -jj branch option merges the changes made between the result-

ing revision and the revision that it is based on (e.g., if the tag refers to a branch, ccvvss will merge all changes made in that branch into your working file).

With two -jj options, ccvvss will merge in the changes between the

two respective revisions. This can be used to ``remove'' a cer-

tain delta from your working file.

In addition, each -jj option can contain on optional date speci-

fication 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. An example might be what `ccvvss iimmppoorrtt' tells you to do when you have just imported sources that have conflicts with local changes:

eexxaammppllee%% ccvvss cchheecckkoouutt -jjTTAAGG::yyeesstteerrddaayy -jjTTAAGG mmoodduullee

Use the -NN option with `-dd dir' to avoid shortening module paths

in your working directory. (Normally, ccvvss shortens paths as much as possible when you specify an explicit target directory.)

Use the -cc option to copy the module file, sorted, to the stan-

dard output, instead of creating or modifying any files or directories in your working directory.

Use the -dd dir option to create a directory called dir for the

working files, instead of using the module name. Unless you

also use -NN, the paths created under dir will be as short as

possible.

Use the -ss option to display per-module status information

stored with the -ss option within the modules file.

ccoommmmiitt [-llnnRR] [-mm 'logmessage' | -ff file] [-rr revision] [files...]

Requires: working directory, repository. Changes: repository. Synonym: ccii Use `ccvvss ccoommmmiitt' when you want to incorporate changes from your working source files into the general source repository. If you don't specify particular files to commit, all of the files in your working current directory are examined. ccoommmmiitt is careful to change in the repository only those files that you have really changed. By default (or if you explicitly specify

the -RR option), files in subdirectories are also examined and

committed if they have changed; you can use the -ll option to

limit ccoommmmiitt to the current directory only. Sometimes you may want to force a file to be committed even though it is

unchanged; this is achieved with the -ff flag, which also has the

effect of disabling recursion (you can turn it back on with -RR

of course). ccoommmmiitt verifies that the selected files are up to date with the current revisions in the source repository; it will notify you, and exit without committing, if any of the specified files must be made current first with `ccvvss uuppddaattee'. ccoommmmiitt does not call the uuppddaattee command for you, but rather leaves that for you to do when the time is right. When all is well, an editor is invoked to allow you to enter a log message that will be written to one or more logging programs

and placed in the source repository file. You can instead spec-

ify the log message on the command line with the -mm option, thus

suppressing the editor invocation, or use the -FF option to spec-

ify that the argument file contains the log message.

The -rr option can be used to commit to a particular symbolic or

numeric revision. For example, to bring all your files up to the revision ``3.0'' (including those that haven't changed), you might do:

eexxaammppllee%% ccvvss ccoommmmiitt -rr33..00

ccvvss 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 -rr option. To create a branch revision, one typ-

ically use the -bb option of the rrttaagg or ttaagg commands. Then,

either cchheecckkoouutt or uuppddaattee can be used to base your sources on the newly created branch. From that point on, all ccoommmmiitt changes made within these working sources will be automatically

added to a branch revision, thereby not perturbing main-line

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 do:

eexxaammppllee%% ccvvss rrttaagg -bb -rrFFCCSS1122 FFCCSS1122PPaattcchh pprroodduuccttmmoodduullee

eexxaammppllee%% ccvvss cchheecckkoouutt -rrFFCCSS1122PPaattcchh pprroodduuccttmmoodduullee

eexxaammppllee%% ccdd pprroodduuccttmmoodduullee

[[[[ hhaacckk aawwaayy ]]]]

eexxaammppllee%% ccvvss ccoommmmiitt

Say you have been working on some extremely experimental soft-

ware, based on whatever revision you happened to checkout last

week. If others in your group would like to work on this soft-

ware with you, but without disturbing main-line development, you

could commit your change to a new branch. Others can then checkout your experimental stuff and utilize the full benefit of ccvvss conflict resolution. The scenario might look like:

eexxaammppllee%% ccvvss ttaagg -bb EEXXPPRR11

eexxaammppllee%% ccvvss uuppddaattee -rrEEXXPPRR11

[[[[ hhaacckk aawwaayy ]]]]

eexxaammppllee%% ccvvss ccoommmmiitt

Others would simply do `ccvvss cchheecckkoouutt -rrEEXXPPRR11 wwhhaatteevveerrmmoodduullee' to

work with you on the experimental change.

ddiiffff [-kkll] [rcsdiffoptions] [[-rr rev1 | -DD date1] [-rr rev2 | -DD

date2]] [files...] Requires: working directory, repository. Changes: nothing. You can compare your working files with revisions in the source repository, with the `ccvvss ddiiffff' 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 ccvvss command

option -rr to specify a particular revision to compare your files

with. Finally, if you use -rr twice, you can see differences

between two revisions in the repository. You can also specify

-DD options to diff against a revision in the past. The -rr and

-DD options can be mixed together with at most two options ever

specified. See rrccssddiiffff(11) for a list of other accepted options. If you don't specify any files, ddiiffff will display differences

for all those files in the current directory (and its subdirec-

tories, unless you use the standard option -ll) that differ from

the corresponding revision in the source repository (i.e. files

that you have changed), or that differ from the revision speci-

fied.

eexxppoorrtt [-ffllNNnnQQqq] -rr rev|-DD date [-dd dir] [-kk kflag] module...

Requires: repository. Changes: current directory. This command is a variant of `ccvvss cchheecckkoouutt'; use it when you

want a copy of the source for module without the ccvvss administra-

tive directories. For example, you might use `ccvvss eexxppoorrtt' to

prepare source for shipment off-site. This command requires

that you specify a date or tag (with -DD or -rr), so that you can

count on reproducing the source you ship to others.

The only non-standard options are `-dd dir' (write the source

into directory dir) and `-NN' (don't shorten module paths).

These have the same meanings as the same options in `ccvvss cchheecckk-

oouutt'.

The -kkvv option is useful when eexxppoorrtt is used. This causes any

keywords to be expanded such that an iimmppoorrtt done at some other site will not lose the keyword revision information. Other kflags may be used with `ccvvss eexxppoorrtt' and are described in ccoo(11).

hhiissttoorryy [-report] [-flags] [-options args] [files...]

Requires: the file `$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//hhiissttoorryy'

Changes: nothing. ccvvss keeps a history file that tracks each use of the cchheecckkoouutt, ccoommmmiitt, rrttaagg, uuppddaattee, and rreelleeaassee commands. You can use `ccvvss hhiissttoorryy' to display this information in various formats.

Warning: `ccvvss hhiissttoorryy' uses `-ff', `-ll', `-nn', and `-pp' in ways

that conflict with the descriptions in COMMON COMMAND OPTIONS.

Several options (shown above as -report) control what kind of

report is generated:

-cc Report on each time ccoommmmiitt was used (i.e., each time the

repository was modified).

-mm module

Report on a particular module. (You can meaningfully use -mm

more than once on the command line.)

-oo Report on checked-out modules.

-TT Report on all tags.

-xx type

Extract a particular set of record types X from the ccvvss his-

tory. The types are indicated by single letters, which you may specify in combination. Certain commands have a single record type: cchheecckkoouutt (type `O'), rreelleeaassee (type `F'), and rrttaagg (type `T'). One of four record types may result from an

uuppddaattee: `W', when the working copy of a file is deleted dur-

ing update (because it was gone from the repository); `U', when a working file was copied from the repository; `G', when a merge was necessary and it succeeded; and 'C', when a merge was necessary but collisions were detected (requiring manual merging). Finally, one of three record types results from ccoommmmiitt: `M', when a file was modified; `A', when a file is first added; and `R', when a file is removed.

-ee Everything (all record types); equivalent to specifying

`-xxMMAACCFFRROOGGWWUUTT'.

-zz zone

Use time zone zone when outputting history records. The zone name LLTT stands for local time; numeric offsets stand for hours and minutes ahead of UTC. For example, ++00553300 stands for 5 hours and 30 minutes ahead of (i.e. east of) UTC.

The options shown as -flags constrain the report without requiring

option arguments:

-aa Show data for all users (the default is to show data only for

the user executing `ccvvss hhiissttoorryy').

-ll Show last modification only.

-ww Show only the records for modifications done from the same

working directory where `ccvvss hhiissttoorryy' is executing.

The options shown as -options args constrain the report based on

an argument:

-bb str

Show data back to a record containing the string str in either the module name, the file name, or the repository path.

-DD date

Show data since date.

-pp repository

Show data for a particular source repository (you can specify

several -pp options on the same command line).

-rr rev

Show records referring to revisions since the revision or tag named rev appears in individual RCS files. Each RCS file is searched for the revision or tag.

-tt tag

Show records since tag tag was last added to the history

file. This differs from the -rr flag above in that it reads

only the history file, not the RCS files, and is much faster.

-uu name

Show records for user name.

iimmppoorrtt [-options] repository vendortag releasetag...

Requires: Repository, source distribution directory. Changes: repository. Use `ccvvss iimmppoorrtt' to incorporate an entire source distribution from an outside source (e.g., 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 mod-

ule 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, iimmppoorrtt creates it. When you use iimmppoorrtt for updates to source that has been modified in your source repository (since a prior iimmppoorrtt), it will notify

you of any files that conflict in the two branches of develop-

ment; use `ccvvss cchheecckkoouutt -jj' to reconcile the differences, as

iimmppoorrtt instructs you to do. By default, certain file names are ignored during `ccvvss iimmppoorrtt': 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. For an up to date list of ignored file names, see the Cederqvist manual (as

described in the SEE ALSO section of this manpage).

The outside source is saved in a first-level branch, by default

`11..11..11'. Updates are leaves of this branch; for example, files from the first imported collection of source will be revision `11..11..11..11', then files from the first imported update will be revision `11..11..11..22', 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 (e.g., for `11..11..11'). You must also specify at least one releasetag to identify the files at the leaves created each time you execute `ccvvss iimmppoorrtt'.

One of the standard ccvvss command options is available: -mm mes-

sage. If you do not specify a logging message with -mm, your

editor is invoked (as with ccoommmmiitt) to allow you to enter one. There are three additional special options.

Use `-dd' to specify that each file's time of last modification

should be used for the checkin date and time.

Use `-bb branch' to specify a first-level branch other than

`11..11..11'.

Use `-II name' to specify file names that should be ignored dur-

ing iimmppoorrtt. You can use this option repeatedly. To avoid

ignoring any files at all (even those ignored by default), spec-

ify `-II !!'.

lloogg [-ll] rlog-options [files...]

Requires: repository, working directory. Changes: nothing. Synonym: rrlloogg Display log information for files. Among the more useful

options are -hh to display only the header (including tag defini-

tions, but omitting most of the full log); -rr to select logs on

particular revisions or ranges of revisions; and -dd to select

particular dates or date ranges. See rrlloogg(11) for full explana-

tions. This command is recursive by default, unless the -ll

option is specified.

rrddiiffff [-flags] [-VV vn] [-rr t|-DD d [-rr t2|-DD d2]] modules...

Requires: repository. Changes: nothing. Synonym: ppaattcchh Builds a Larry Wall format ppaattcchh(11) file between two releases, that can be fed directly into the ppaattcchh program to bring an old

release up-to-date with the new release. (This is one of the

few ccvvss commands that operates directly from the repository, and doesn't require a prior cchheecckkoouutt.) The diff output is sent to the standard output device. You can specify (using the standard

-rr and -DD 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 -pp

option to the ppaattcchh command when patching the old sources, so that ppaattcchh is able to find the files that are located in other directories.

The standard option flags -ff, and -ll are available with this

command. There are also several special options flags:

If you use the -ss 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 find-

ing out, for example, which files have changed between two dates or revisions.

If you use the -tt 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 -uu option, the patch output uses the newer ``uni-

diff'' format for context diffs.

You can use -cc to explicitly specify the `ddiiffff -cc' form of con-

text diffs (which is the default), if you like.

rreelleeaassee [-ddQQqq] modules...

Requires: Working directory. Changes: Working directory, history log.

This command is meant to safely cancel the effect of `ccvvss cchheecckk-

oouutt''..' Since ccvvss 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 ccvvss history file that you've abandoned your checkout. Use `ccvvss rreelleeaassee' to avoid these problems. This command checks

that no un-committed changes are present; that you are executing

it from immediately above, or inside, a ccvvss 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, `ccvvss rreelleeaassee' leaves a record of its execution (attesting to your intentionally abandoning your checkout) in the ccvvss history log.

You can use the -dd flag to request that your working copies of

the source files be deleted if the rreelleeaassee succeeds.

rreemmoovvee [-llRR] [files...]

Requires: Working directory. Changes: Working directory. Synonyms: rrmm, ddeelleettee Use this command to declare that you wish to remove files from the source repository. Like most ccvvss commands, `ccvvss rreemmoovvee' 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 ccoommmmiitt; at that point, the corresponding RCS files in the source repository are moved into the `AAttttiicc' directory (also within the source repository). This command is recursive by default, scheduling all physically removed files that it finds for removal by the next ccoommmmiitt. Use

the -ll option to avoid this recursion, or just specify that

actual files that you wish remove to consider.

rrttaagg [-ffaallnnRRQQqq] [-bb] [-dd] [-rr tag | -DD date] symbolictag modules...

Requires: repository. Changes: repository. Synonym: rrffrreeeezzee You can use this command to assign symbolic tags to particular, explicitly specified source versions in the repository. `ccvvss rrttaagg' works directly on the repository contents (and requires no prior cchheecckkoouutt). Use `ccvvss ttaagg' instead, to base the selection of versions to tag on the contents of your working directory.

In general, tags (often the symbolic names of software distribu-

tions) should not be removed, but the -dd option is available as

a means to remove completely obsolete symbolic names if neces-

sary (as might be the case for an Alpha release, say).

`ccvvss rrttaagg' will not move a tag that already exists. With the -FF

option, however, `ccvvss rrttaagg' will re-locate any instance of sym-

bolictag that already exists on that file to the new repository

versions. Without the -FF option, attempting to use `ccvvss rrttaagg'

to apply a tag that already exists on that file will produce an error message.

The -bb option makes the tag a ``branch'' tag, allowing concur-

rent, isolated development. This is most useful for creating a patch to a previously released software distribution.

You can use the standard -rr and -DD options to tag only those

files that already contain a certain tag. This method would be used to rename a tag: tag only the files identified by the old tag, then delete the old tag, leaving the new tag on exactly the same files as the old tag. rrttaagg executes recursively by default, tagging all subdirectories of modules you specify in the argument. You can restrict its

operation to top-level directories with the standard -ll option;

or you can explicitly request recursion with -RR.

The modules database can specify a program to execute whenever a tag is specified; a typical use is to send electronic mail to a

group of interested parties. If you want to bypass that pro-

gram, use the standard -nn option.

Use the -aa option to have rrttaagg look in the `AAttttiicc' for removed

files that contain the specified tag. The tag is removed from

these files, which makes it convenient to re-use a symbolic tag

as development continues (and files get removed from the up-com-

ing distribution).

ssttaattuuss [-llRRqqQQ] [-vv] [files...]

Requires: working directory, repository. Changes: nothing. Display a brief report on the current status of files with respect to the source repository, including any ``sticky'' tags,

dates, or -kk options. (``Sticky'' options will restrict how

`ccvvss uuppddaattee' operates until you reset them; see the description

of `ccvvss uuppddaattee -AA......'.)

You can also use this command to anticipate the potential impact of a `ccvvss uuppddaattee' on your working source directory. If you do not specify any files explicitly, reports are shown for all files that ccvvss has placed in your working directory. You can limit the scope of this search to the current directory itself

(not its subdirectories) with the standard -ll option flag; or

you can explicitly request recursive status reports with the -RR

option.

The -vv option causes the symbolic tags for the RCS file to be

displayed as well.

ttaagg [-llQQqqRR] [-FF] [-bb] [-dd] [-rr tag | -DD date] [-ff] symbolictag

[files...] Requires: working directory, repository. Changes: repository. Synonym: ffrreeeezzee

Use this command to assign symbolic tags to the nearest reposi-

tory versions to your working sources. The tags are applied immediately to the repository, as with rrttaagg. One use for tags is to record a ``snapshot'' of the current sources when the software freeze date of a project arrives. As bugs are fixed after the freeze date, only those changed sources

that are to be part of the release need be re-tagged.

The symbolic tags are meant to permanently record which revi-

sions of which files were used in creating a software distribu-

tion. The cchheecckkoouutt, eexxppoorrtt and uuppddaattee commands allow you to extract an exact copy of a tagged release at any time in the future, regardless of whether files have been changed, added, or removed since the release was tagged.

You can use the standard -rr and -DD options to tag only those

Specifying the -ff flag in addition to the -rr or -DD flags will

tag those files named on the command line even if they do not contain the old tag or did not exist on the specified date.

By default (without a -rr or -DD flag) the versions to be tagged

are supplied implicitly by the ccvvss records of your working files' history rather than applied explicitly.

If you use `ccvvss ttaagg -dd symbolictag......', the symbolic tag you

specify is deleted instead of being added. Warning: Be very certain of your ground before you delete a tag; doing this effectively discards some historical information, which may later turn out to have been valuable.

`ccvvss ttaagg' will not move a tag that already exists. With the -FF

option, however, `ccvvss ttaagg' will re-locate any instance of sym-

bolictag that already exists on that file to the new repository

versions. Without the -FF option, attempting to use `ccvvss ttaagg' to

apply a tag that already exists on that file will produce an error message.

The -bb option makes the tag a ``branch'' tag, allowing concur-

rent, isolated development. This is most useful for creating a patch to a previously released software distribution. Normally, ttaagg executes recursively through subdirectories; you

can prevent this by using the standard -ll option, or specify the

recursion explicitly by using -RR.

uuppddaattee [-AAddffllPPppQQqqRR] [-dd] [-rr tag|-DD date] files...

Requires: repository, working directory. Changes: working directory. After you've run cchheecckkoouutt to create your private copy of source from the common repository, other developers will continue

changing the central source. From time to time, when it is con-

venient in your development process, you can use the uuppddaattee com-

mand from within your working directory to reconcile your work with any revisions applied to the source repository since your last cchheecckkoouutt or uuppddaattee. uuppddaattee keeps you informed of its progress by printing a line for each file, prefaced with one of the characters `UU AA RR MM CC ??' to indicate the status of the file:

UU file The file was brought up to date with respect to the reposi-

tory. This is done for any file that exists in the reposi-

tory but not in your source, and for files that you haven't changed but are not the most recent versions available in the repository. AA file The file has been added to your private copy of the sources, and will be added to the source repository when you run `ccvvss ccoommmmiitt' on the file. This is a reminder to you that the file needs to be committed. RR file The file has been removed from your private copy of the sources, and will be removed from the source repository when you run `ccvvss ccoommmmiitt' on the file. This is a reminder to you that the file needs to be committed. MM file The file is modified in your working directory. `MM' can indicate one of two states for a file you're working on: either there were no modifications to the same file in the repository, so that your file remains as you last saw it; or there were modifications in the repository as well as in your copy, but they were merged successfully, without conflict, in your working directory. CC file A conflict was detected while trying to merge your changes to file with changes from the source repository. file (the copy in your working directory) is now the result of merging the two versions; an unmodified copy of your file is also in your

working directory, with the name `..##file..version', where ver-

sion is the revision that your modified file started from. (Note that some systems automatically purge files that begin

with `..##' if they have not been accessed for a few days. If

you intend to keep a copy of your original file, it is a very good idea to rename it.) ?? file file is in your working directory, but does not correspond to anything in the source repository, and is not in the list of

files for ccvvss to ignore (see the description of the -II

option).

Use the -AA option to reset any sticky tags, dates, or -kk options.

(If you get a working copy of a file by using one of the -rr, -DD,

or -kk options, ccvvss remembers the corresponding tag, date, or kflag

and continues using it on future updates; use the -AA option to

make ccvvss forget these specifications, and retrieve the ``head'' version of the file).

The -jjbranch option merges the changes made between the resulting

revision and the revision that it is based on (e.g., if the tag refers to a branch, ccvvss will merge all changes made in that branch into your working file).

With two -jj options, ccvvss will merge in the changes between the two

respective revisions. This can be used to ``remove'' a certain delta from your working file. E.g., If the file foo.c is based on revision 1.6 and I want to remove the changes made between 1.3 and 1.5, I might do:

eexxaammppllee%% ccvvss uuppddaattee -jj11..55 -jj11..33 ffoooo..cc ## nnoottee tthhee oorrddeerr......

In addition, each -jj option can contain on optional date specifi-

cation which, when used with branches, can limit the chosen revi-

sion to one within a specific date. An optional date is specified by adding a colon (:) to the tag.

-jjSSyymmbboolliiccTTaagg::DDaatteeSSppeecciiffiieerr

Use the -dd option to create any directories that exist in the

repository if they're missing from the working directory. (Nor-

mally, update acts only on directories and files that were already enrolled in your working directory.) This is useful for updating directories that were created in the repository since the initial

cchheecckkoouutt; but it has an unfortunate side effect. If you deliber-

ately avoided certain directories in the repository when you cre-

ated your working directory (either through use of a module name or by listing explicitly the files and directories you wanted on

the command line), then updating with -dd will create those direc-

tories, which may not be what you want.

Use -II name to ignore files whose names match name (in your work-

ing directory) during the update. You can specify -II more than

once on the command line to specify several files to ignore. By default, uuppddaattee ignores files whose names match certain patterns; for an up to date list of ignored file names, see the Cederqvist

manual (as described in the SEE ALSO section of this manpage).

Use `-II !!' to avoid ignoring any files at all.

The standard ccvvss command options -ff, -kk, -ll, -PP, -pp, and -rr are

also available with uuppddaattee. FILES For more detailed information on ccvvss supporting files, see ccvvss(55). Files in home directories: .cvsrc The ccvvss initialisation file. Lines in this file can be used to specify default options for each ccvvss command. For example the

line `ddiiffff -cc' will ensure that `ccvvss ddiiffff' is always passed the

-cc option in addition to any other options passed on the command

line. .cvswrappers Specifies wrappers to be used in addition to those specified in the CVSROOT/cvswrappers file in the repository. Files in working directories: CVS A directory of ccvvss administrative files. Do not delete. CVS/Entries List and status of files in your working directory. CVS/Entries.Backup A backup of `CCVVSS//EEnnttrriieess'. CVS/Entries.Static Flag: do not add more entries on `ccvvss uuppddaattee'. CVS/Root Pathname to the repository ( CVSROOT ) location at the time of checkout. This file is used instead of the CVSROOT environment

variable if the environment variable is not set. A warning mes-

sage will be issued when the contents of this file and the CVS-

ROOT environment variable differ. The file may be over-ridden

by the presence of the CVSIGNOREREMOTEROOT environment vari-

able. CVS/Repository

Pathname to the corresponding directory in the source reposi-

tory. CVS/Tag

Contains the per-directory ``sticky'' tag or date information.

This file is created/updated when you specify -rr or -DD to the

cchheecckkoouutt or uuppddaattee commands, and no files are specified. CVS/Checkin.prog Name of program to run on `ccvvss ccoommmmiitt'. CVS/Update.prog Name of program to run on `ccvvss uuppddaattee'. Files in source repositories:

$CVSROOT/CVSROOT

Directory of global administrative files for repository. CVSROOT/commitinfo,v Records programs for filtering `ccvvss ccoommmmiitt' requests. CVSROOT/cvswrappers,v Records ccvvss wrapper commands to be used when checking files into and out of the repository. Wrappers allow the file or directory to be processed on the way in and out of CVS. The intended uses are many, one possible use would be to reformat a C file before the file is checked in, so all of the code in the repository looks the same. CVSROOT/editinfo,v Records programs for editing/validating `ccvvss ccoommmmiitt' log entries. CVSROOT/history Log file of ccvvss transactions. CVSROOT/loginfo,v Records programs for piping `ccvvss ccoommmmiitt' log entries. CVSROOT/modules,v Definitions for modules in this repository. CVSROOT/rcsinfo,v

Records pathnames to templates used during a `ccvvss ccoommmmiitt' opera-

tion. CVSROOT/taginfo,v Records programs for validating/logging `ccvvss ttaagg' and `ccvvss rrttaagg' operations. MODULE/Attic Directory for removed source files.

#cvs.lock

A lock directory created by ccvvss when doing sensitive changes to the source repository.

#cvs.tfl.pid

Temporary lock file for repository.

#cvs.rfl.pid

A read lock.

#cvs.wfl.pid

A write lock. ENVIRONMENT VARIABLES CVSROOT Should contain the full pathname to the root of the ccvvss source repository (where the RCS files are kept). This information

must be available to ccvvss for most commands to execute; if CVS-

ROOT is not set, or if you wish to override it for one invoca-

tion, you can supply it on the command line: `ccvvss -dd cvsroot

cvscommand......' You may not need to set CVSROOT if your ccvvss

binary has the right path compiled in; use `ccvvss -vv' to display

all compiled-in paths.

CVSREAD If this is set, cchheecckkoouutt and uuppddaattee will try hard to make the

files in your working directory read-only. When this is not

set, the default behavior is to permit modification of your working files. RCSBIN Specifies the full pathname where to find RCS programs, such as ccoo(11) and ccii(11) (CVS 1.9 and older). CVSEDITOR Specifies the program to use for recording log messages during ccoommmmiitt. If not set, the EDITOR environment variable is used instead. If EDITOR is not set either, the default is //uussrr//uuccbb//vvii. CVSIGNOREREMOTEROOT If this variable is set then ccvvss will ignore all references to remote repositories in the CVS/Root file. CVSRSH ccvvss uses the contents of this variable to determine the name of the remote shell command to use when starting a ccvvss server. If this variable is not set then `rrsshh' is used. CVSSERVER ccvvss uses the contents of this variable to determine the name of the ccvvss server command. If this variable is not set then `ccvvss' is used. CVSWRAPPERS This variable is used by the `ccvvsswwrraappppeerrss' script to determine the name of the wrapper file, in addition to the wrappers defaults contained in the repository (CVSROOT/cvswrappers) and the user's home directory (~/.cvswrappers). AUTHORS Dick Grune Original author of the ccvvss shell script version posted to ccoommpp..ssoouurrcceess..uunniixx in the volume6 release of December, 1986. Credited with much of the ccvvss conflict resolution algorithms. Brian Berliner Coder and designer of the ccvvss program itself in April, 1989, based on the original work done by Dick. Jeff Polk Helped Brian with the design of the ccvvss module and vendor branch support and author of the cchheecckkiinn(11) shell script (the ancestor of `ccvvss iimmppoorrtt'). And many others too numerous to mention here.