ci(1)

ci(1)

NAME

ci - check in RCS revisions

SYNOPSIS

ci [ options ] ®le...

DESCRIPTION

ci stores new revisions into RCS ®les. Each ®le name ending in ,v is treated as an RCS ®le; all others are assumed to be working ®les. ci deposits the contents of each working ®le into the corresponding RCS ®le (see rcsintro(5)).

If the RCS ®le does not exist, ci creates it and deposits the contents of the working ®le as the initial revi- sion. The default number is "1.1". The access list is initialized to empty. Instead of the log message, ci requests descriptive text (see the -toption below).

An RCS ®le created by ci inherits the read and execute permissions from the working ®le. If the RCS ®le exists, ci preserves its read and execute permissions. ci always turns off all write permissions of RCS ®les.

The caller of the command must have read/write permission for the directories containing the RCS ®le and the working ®le, and read permission for the RCS ®le itself. A number of temporary ®les are created. A semaphore ®le is created in the directory containing the RCS ®le. ci always creates a new RCS ®le and unlinks the old one; therefore links to RCS ®les are useless.

For ci to work, the user's login must be in the access list unless the access list is empty, the user is the owner of the ®le, or the user is super-user.

Normally, ci checks whether the revision to be deposited is different from the preceding one. If it is not different, ci either aborts the deposit (if -qis given) or asks whether to abort (if -qis omitted). A deposit can be forced with the -foption.

If suf®cient memory is not available for checking the difference between the revision to be deposited and the preceding one, then either swap or maxdsiz values can be increased.

For each revision deposited, ci prompts for a log message. The log message should summarize the change and must be terminated with a line containing a single "." or a control-D. If several ®les are being checked in, ci asks whether or not to reuse the log message from the previous ®le. If the standard input is not a terminal, ci suppresses the prompt and uses the same log message for all ®les (see -moption below.

The number of the deposited revision can be given with any of the options -r, -f, -k, -l, -u, or -q(see -roption below).

To add a new revision to an existing branch, the head revision on that branch must be locked by the caller. Otherwise, only a new branch can be created. This restriction is not enforced for the owner of the ®le, unless locking is set to strict (see rcs(1)). A lock held by someone else can be broken with the rcs command (see rcs(1)).

Options

 

 

 

-f[rev ]

Forces a deposit. The new revision is deposited even if it is not different from the preceding

 

one.

 

 

-k[rev ]

Searches the working ®le for keyword values to determine its revision number, creation

 

date, author, and state (see co(1)), and assigns these values to the deposited revision,

 

rather than computing them locally. A revision number given with a command option over-

 

rides the number in the working ®le. This option is useful for software distribution. A revi-

 

sion that is sent to several sites should be checked in with the

-koption at these sites to

 

preserve its original number, date, author, and state.

 

-l[rev ]

Works like -r, except it performs an additional co -lfor the deposited revision. Thus,

 

the deposited revision is immediately checked out again and locked. This is useful for sav-

 

ing a revision although one wants to continue editing it after the check-in.

-m"msg"

Uses the string msg as the log message for all revisions checked in.

-n"name"

Assigns the symbolic name name to the checked-in revision.

ci prints an error message

 

if name is already assigned to another number.

 

-N"name"

Same as -n, except that it overrides a previous assignment of name.

HP-UX Release 11i: December 2000

− 1 −

Section 1−91

c