home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 10 Tools
/
10-Tools.zip
/
rcstxi11.zip
/
rcstexi.110
/
ci.tex
< prev
next >
Wrap
Text File
|
1997-03-30
|
36KB
|
981 lines
@c
@c ================================================================================
@c Edition 1.1
@c of the Texinfo-manuals for the
@c (R)evision (C)ontrol (S)ystem
@c Version 5.7
@c
@c (c) 1982, 1988, 1989 Walter F. Tichy.
@c (c) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert.
@c (c) 1996, 1997 Karl Heinz Marbaise (doing converting job)
@c ================================================================================
@c
@c Discription:
@c Discription about ci command.
@c
@c Authors:
@c Walter Tichy,
@c Paul Eggert,
@c Karl Heinz Marbaise (doing converting job)
@c
@c e-mail:
@c Internet: KHMarbaise@p69.ks.fido.de
@c Fido-net: 2:2452/117.69
@c
@c Bugs, question:
@c to above e-mail adress.
@c
@c License:
@c The "Texinfo Edition of the RCS V5.7 manuals" are free
@c software; you can redistribute it and/or modify it under
@c the terms of the GNU General Public License as published
@c by the Free Software Foundation; either version 2, or (at
@c your option) any later version.
@c
@c The "Texinfo Edition of the RCS V5.7 manuals" are distributed
@c in the hope that they will be useful, but WITHOUT ANY WARRANTY;
@c without even the implied warranty of MERCHANTABILITY or
@c FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
@c License for more details.
@c
@c You should have received a copy of the GNU General Public License
@c along with the "Texinfo Edition of the RCS V5.7 manuals"; see the
@c file COPYING. If not, write to the:
@c Free Software Foundation,
@c 59 Temple Place - Suite 330,
@c Boston, MA 02111-1307, USA.
@c
@c See \rcstxi.110\COPYING for details.
@c
@c ================================================================================
@c
@c
@c $Id: CI.TEX 1.2 1997/03/30 22:53:09 KHM Exp $
@c
@c =============================================================================
@c ci -- check in RCS revsisions
@c -----------------------------------------------------------------------------
@node CheckIn,CheckOut,Synopsis,Top
@chapter ci -- check in RCS revisions
@cindex ci
@cindex check in
@menu
* ciIntro:: Introduction to @code{ci}.
* ciOptions:: command line options of @code{ci}.
* ciFileNaming:: File naming.
* ciExamples:: Examples.
* ciFileModes:: File modes.
* ciFiles:: Files.
* setuid use:: Using of uid.
* ciEnv:: Environment which can change
the behaviour of @code{ci} and
other RCS commands.
* ciDiag:: Diagnostic output of @code{ci}.
@end menu
@c =============================================================================
@c ci -- check in RCS revsisions
@c Description
@c -----------------------------------------------------------------------------
@node ciIntro,ciOptions,,CheckIn
@section ci description
@code{ci} stores new revisions into RCS files. Each pathname
matching an RCS suffix is taken to be an RCS file. All others are
assumed to be working files containing new revisions. @code{ci}
deposits the contents of each working file into the corresponding
RCS file. If only a working file is given, @code{ci} tries to
find the corresponding RCS file in an RCS subdirectory and then
in the working file's directory. For more details, @xref{ciFileNaming}
below.
For @code{ci} to work, the caller's login must be on the access
list, except if the access list is empty or the caller is the
superuser or the owner of the file. To append a new revision to
an existing branch, the tip 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
file if non-strict locking is used (see @ref{rcs}). A lock held
by someone else can be broken with the @code{rcs} command.
Unless the @code{-f} option is given, @code{ci} checks whether
the revision to be deposited differs from the preceding one. If
not, instead of creating a new revision @code{ci} reverts to the
preceding one. To revert, ordinary @code{ci} removes the working
file and any lock; @code{ci -l} keeps and @code{ci -u}
removes any lock, and then they both generate a new working file
much as if @code{co -l} or @code{co -u} had been applied to
the preceding revision. When reverting, any @code{-n} and
@code{-s} options apply to the preceding revision.
For each revision deposited, @code{ci} prompts for a log message.
The log message should summarize the change and must be
terminated by end-of-file or by a line containing @code{.} by
itself. If several files are checked in @code{ci} asks whether to
reuse the previous log message. If the standard input is not a
terminal, @code{ci} suppresses the prompt and uses the same log
message for all files(Option @code{-m} of @code{ci}, @ref{ciOptm}).
If the RCS file does not exist, @code{ci} creates it and deposits
the contents of the working file as the initial revision (default
number: @code{1.1} ). The access list is initialized to empty.
Instead of the log message,
@code{ci} requests descriptive text
(Option @code{-t} of @code{ci}, @ref{ciOptt})
below).
The number @code{rev} of the deposited revision can be given by any
of the options @code{-f}, @code{-i}, @code{-I}, @code{-j},
@code{-k}, @code{-l}, @code{-M}, @code{-q}, @code{-r} or @code{-u}
@code{rev} can be symbolic, numeric, or mixed.
Symbolic names in
@code{rev} must already be defined;
see the Option @code{-n} (@ref{ciOptn}) and @code{-N} (@ref{ciOptNu})
options for assigning names during checkin.
If @code{rev} is @code{$}, @code{ci} determines the revision
number from keyword values in the working file.
If @code{rev} begins with a period, then the default branch
(normally the trunk) is prepended to it. If @code{rev} is a
branch number followed by a period, then the latest revision on
that branch is used.
If @code{rev} is a revision number, it must be higher than the
latest one on the branch to which @code{rev} belongs, or must
start a new branch.
If @code{rev} is a branch rather than a revision number, the new
revision is appended to that branch. The level number is
obtained by incrementing the tip revision number of that branch.
If @code{rev} indicates a non-existing branch, that branch is
created with the initial revision numbered @code{rev .1.}
If @code{rev} is omitted, @code{ci} tries to derive the new
revision number from the caller's last lock. If the caller has
locked the tip revision of a branch, the new revision is appended
to that branch. The new revision number is obtained by
incrementing the tip revision number. If the caller locked a
non-tip revision, a new branch is started at that revision by
incrementing the highest branch number at that revision. The
default initial branch and level numbers are @code{1.}.
If @code{rev} is omitted and the caller has no lock, but owns the
file and locking is not set to @code{strict}, then the revision
is appended to the default branch (normally the trunk; see the
option @code{-b} of @code{rcs} @ref{rcsOptb}).
Exception: On the trunk, revisions can be appended to the end, but
not inserted.
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c -----------------------------------------------------------------------------
@node ciOptions,ciFileNaming,ciIntro,CheckIn
@section Command line options of ci
@ifinfo
Overview off all options which can be given to
@code{Synopsis}: ci [options] file @dots{}
@code{ci}.
@end ifinfo
@menu
* ciOptr:: -r Revision
* ciOptl:: -l lock a revision.
* ciOptu:: -u unlock a revision.
* ciOptf:: -f force a deposit.
* ciOptk:: -k search for keyword values.
* ciOptq:: -q quiet mode
* ciOpti:: -i initial
* ciOptj:: -j just check in
* ciOptIu:: -I interacitve mode
* ciOptd:: -d date
* ciOptMu:: -M
* ciOptm:: -m log message
* ciOptn:: -n symbolic name
* ciOptNu:: -N replace an existing symbolic name
* ciOpts:: -s set state
* ciOptt:: -t discription
* ciOptTu:: -T modification time
* ciOptw:: -w login
* ciOptV:: -V Version of RCS; Emulate RCS Version
* ciOptx:: -x Suffixes
* ciOptz:: -z Time zoone for output.
@end menu
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -r
@c -----------------------------------------------------------------------------
@node ciOptr,ciOptl,,ciOptions
@subsection Check in revision
@cindex -r
@cindex revision
@table @code
@item -r@file{rev}
Check in revision @b{rev}.
@item -r
The bare @code{-r} option (without any revision) has an unusual
meaning in @code{ci}. With other RCS commands, a bare @code{-r}
option specifies the most recent revision on the default branch,
but with @code{ci}, a bare @code{-r} option reestablishes the
default behavior of releasing a lock and removing the working
file, and is used to override any default @code{-l} or @code{-u}
options established by shell aliases or scripts.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -l
@c -----------------------------------------------------------------------------
@node ciOptl,ciOptu,ciOptr,ciOptions
@subsection lock a revision
@cindex -l
@cindex lock a revision
@table @code
@item -l[@file{rev}]
works like @code{-r}, except it performs an additional
@code{co-l} for the deposited revision. Thus, the
deposited revision is immediately checked out again and
locked. This is useful for saving a revision although
one wants to continue editing it after the checkin.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -u
@c -----------------------------------------------------------------------------
@node ciOptu,ciOptf,ciOptl,ciOptions
@subsection unlock a revision
@cindex -u
@cindex unlock a revision
@table @code
@item -u[@file{rev}]
works like @code{-l}, except that the deposited revision is not
locked. This lets one read the working file immediately after
checkin.
The @code{-l}, bare @code{-r}, and @code{-u} options are mutually
exclusive and silently override each other. For example, @code{ci
-u -r} is equivalent to @code{ci -r} because bare @code{-r}
overrides @code{-u}.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -f
@c -----------------------------------------------------------------------------
@node ciOptf,ciOptk,ciOptu,ciOptions
@subsection force a deposit
@cindex -f
@cindex force a deposit
@table @code
@item -f[@file{rev}]
forces a deposit; the new revision is deposited even it is not
different from the preceding one.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -k
@c -----------------------------------------------------------------------------
@node ciOptk,ciOptq,ciOptf,ciOptions
@subsection keyword values
@cindex -k
@cindex keyword values
@table @code
@item -k[@file{rev}]
searches the working file for keyword values to determine its
revision number, creation date, state, and author (see
@ref{CheckOut}), and assigns these values to the deposited
revision, rather than computing them locally. It also generates a
default login message noting the login of the caller and the
actual checkin date. This option is useful for software
distribution. A revision that is sent to several sites should be
checked in with the @code{-k} option at these sites to preserve
the original number, date, author, and state. The extracted
keyword values and the default log message can be overridden with
the options @code{-d}, @code{-m}, @code{-s}, @code{-w}, and any
option that carries a revision number.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -q
@c -----------------------------------------------------------------------------
@node ciOptq,ciOpti,ciOptk,ciOptions
@subsection quiet
@cindex -q
@cindex quiet
@cindex diagnostic
@table @code
@item -q[@file{rev}]
quiet mode; diagnostic output is not printed. A revision that is
not different from the preceding one is not deposited, unless
@code{-f} is given.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -i
@c -----------------------------------------------------------------------------
@node ciOpti,ciOptj,ciOptq,ciOptions
@subsection initial check in
@cindex -i
@cindex initial checkin
@table @code
@item -i[@file{rev}]
initial checkin; report an error if the RCS file already exists.
This avoids race conditions in certain applications.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -j
@c -----------------------------------------------------------------------------
@node ciOptj,ciOptIu,ciOpti,ciOptions
@subsection just check in
@cindex -j
@cindex just checkin
@table @code
@item -j[@file{rev}]
just checkin and do not initialize;
report an error if the RCS file does not already exist.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -I
@c -----------------------------------------------------------------------------
@node ciOptIu,ciOptd,ciOptj,ciOptions
@subsection interactive mode
@cindex -I
@cindex interactive mode
@cindex interactive
@table @code
@item -I[@file{rev}]
interactive mode; the user is prompted and questioned
even if the standard input is not a terminal.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -d
@c -----------------------------------------------------------------------------
@node ciOptd,ciOptMu,ciOptIu,ciOptions
@subsection date
@cindex -d
@cindex date
@table @code
@item -d[@file{date}]
uses @code{date} for the checkin date and time. The @code{date}
is specified in free format as explained in @code{co} (@xref{CheckOut}).
This is useful for lying about the checkin date, and for @code{-k} if
no date is available. If @code{date} is empty, the working file's
time of last modification is used.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -M
@c -----------------------------------------------------------------------------
@node ciOptMu,ciOptm,ciOptd,ciOptions
@subsection modification time
@cindex -M
@cindex modification time
@table @code
@item -M[@file{rev}]
Set the modification time on any new working file to be the date
of the retrieved revision. For example, @code{ci -d -M -u f} does
not alter @file{f} 's modification time, even if @file{f}'s
contents change due to keyword substitution. Use this option with
care; it can confuse @code{MAKE}.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -m
@c -----------------------------------------------------------------------------
@node ciOptm,ciOptn,ciOptMu,ciOptions
@subsection log message
@cindex -m
@cindex log message
@table @code
@item -m[@file{msg}]
uses the string @code{msg} as the log message for all revisions
checked in. By convention, log messages that start with @code{#}
are comments and are ignored by programs like GNU Emacs's
@code{vc} package. Also, log messages that start with
@code{@{ clumpname @}} (followed by white space) are meant to be
clumped together if possible, even if they are associated with
different files; the @code{@{ clumpname @}} label is used only
for clumping, and is not considered to be part of the log message
itself.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -n
@c -----------------------------------------------------------------------------
@node ciOptn,ciOptNu,ciOptm,ciOptions
@subsection symbolic name
@cindex -n
@cindex symbolic name
@cindex tag
@table @code
@item -n[@file{name}]
assigns the symbolic name @code{name} to the number of the
checked-in revision. @code{ci} prints an error message if
@code{name} is already assigned to another number.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -N
@c -----------------------------------------------------------------------------
@node ciOptNu,ciOpts,ciOptn,ciOptions
@subsection replace symbolic name
@cindex -N
@cindex override symbolic name
@table @code
@item -N[@file{name}]
same as @code{-n}, except that it overrides a previous assignment
of @code{name}.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -s
@c -----------------------------------------------------------------------------
@node ciOpts,ciOptt,ciOptNu,ciOptions
@subsection states
@cindex -s
@cindex states
@table @code
@item -s[@file{state}]
sets the state of the checked-in revision to the identifier
@code{state}. The default state is @code{Exp}.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -t
@c -----------------------------------------------------------------------------
@node ciOptt,ciOptTu,ciOpts,ciOptions
@subsection description
@cindex -t
@cindex -t-
@cindex description
@table @code
@item -t@file{file}
writes descriptive text from the contents of the named
@file{file}
into the RCS file, deleting the existing text.
The @file{file} cannot begin with @code{-}.
@item -t-@file{string}
Write descriptive text from the @file{string} into the RCS file,
deleting the existing text.
The @code{-t} option, in both its forms, has effect only during
an initial checkin; it is silently ignored otherwise.
During the initial checkin, if @code{-t} is not given, @code{ci}
obtains the text from standard input, terminated by end-of-file
or by a line containing @code{.} by itself. The user is prompted
for the text if interaction is possible; see optiom @code{-I}
of @code{ci}(@xref{ciOptIu}).
For backward compatibility with older versions of RCS, a bare
@code{-t} option is ignored.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -T
@c -----------------------------------------------------------------------------
@node ciOptTu,ciOptw,ciOptt,ciOptions
@subsection modification time
@cindex -T
@cindex modification time
@table @code
@item -T
Set the RCS file's modification time to the new revision's time
if the former precedes the latter and there is a new revision;
preserve the RCS file's modification time otherwise. If you have
locked a revision, @code{ci} usually updates the RCs file's
modification time to the current time, because the lock is stored
in the RCS file and removing the lock requires changing the RCS
file. This can create an RCS file newer than the working file in
one of two ways: first, @code{ci -M} can create a working file
with a date before the current time; second, when reverting to
the previous revision the RCS file can change while the working
file remains unchanged. These two cases can cause excessive
recompilation caused by a @code{MAKE} dependency of the working
file on the RCS file. The @code{-T} option inhibits this
recompilation by lying about the RCS file's date. Use this option
with care; it can suppress recompilation even when a checkin of
one working file should affect another working file associated
with the same RCS file. For example, suppose the RCS file's time
is 01:00, the (changed) working file's time is 02:00, some other
copy of the working file has a time of 03:00, and the current
time is 04:00. Then @code{ci -d -T} sets the RCS file's time to
02:00 instead of the usual 04:00; this causes @code{MAKE} to
think (incorrectly) that the other copy is newer than the RCs
file.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -w
@c -----------------------------------------------------------------------------
@node ciOptw,ciOptV,ciOptTu,ciOptions
@subsection login
@cindex -w
@cindex login
@table @code
@item -w@file{login}
uses @code{login} for the author field of the deposited revision.
Useful for lying about the author, and for @code{-k} if no author
is available.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -V, -Vn
@c -----------------------------------------------------------------------------
@node ciOptV,ciOptx,ciOptw,ciOptions
@subsection version and emulation
@cindex -V
@cindex emulate RCS Version
@cindex print RCS Version
@table @code
@item -V
Print RCS's version number.
@item -V@file{n}
Emulate RCS version @code{n}. @xref{coOptV}
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -x
@c -----------------------------------------------------------------------------
@node ciOptx,ciOptz,ciOptV,ciOptions
@subsection suffixes
@cindex -x
@cindex suffixes
@table @code
@item -x@file{suffixes}
specifies the suffixes for RCS files. A nonempty suffix matches
any pathname ending in the suffix. An empty suffix matches any
pathname of the form @code{RCS/@b{path}} or
@code{path1/RCS/path2}. The @code{-x} option can specify a list
of suffixes separated by @code{.} For example, @code{-x,v/}
specifies two suffixes: @code{,v} and the empty suffix. If two or
more suffixes are specified, they are tried in order when looking
for an RCS file; the first one that works is used for that file.
If no RCS file is found but an RCS file can be created, the
suffixes are tried in order to determine the new RCS file's name.
The default for @code{suffixes} is installation-dependent;
normally it is @code{,v/} for hosts like Unix that permit commas
in filenames, and is empty (i.e. just the empty suffix) for other
hosts.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Options
@c option -z
@c -----------------------------------------------------------------------------
@node ciOptz,,ciOptx,ciOptions
@subsection time zoone
@cindex -z
@cindex zoone
@cindex time zoone
@cindex TZ
@table @code
@item -z@file{zoone}
specifies the date output format in keyword substitution, and
specifies the default time zone for @code{date} in the
@code{-d@file{date}} option. The @file{zoone} should be empty, a
numeric UTC offset, or the special string @file{LT} for local
time. The default is an empty @file{zoone}, which uses the
traditional RCS format of UTC without any time zone indication and
with slashes separating the parts of the date; otherwise, times
are output in ISO 8601 format with time zone indication. For
example, if local time is January 11, 1990, 8pm Pacific Standard
Time, eight hours west of UTC, then the time is output as
follows:
@example
@group
@code{Option} @code{time output}
@code{-z} @code{1990/01/11 04:00:00} (default)
@code{-zLT} @code{1990-01-11 20:00:00-0800}
@code{-z+0530} @code{1990-01-11 09:30:00+0530}
@end group
@end example
This option
does not affect dates stored in RCS files, which are always UTC.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c FILE NAMING
@c -----------------------------------------------------------------------------
@node ciFileNaming,ciExamples,ciOptions,CheckIn
@section FILE NAMING
Pairs of RCS files and working files can be specified in three
ways (see also the example section).
@enumerate
@item Both the file and the working file are given.
The RCS pathname is of the form @code{path1/workfileX}
and the working pathname is of the form
@code{path2/workfile} where @code{path1/} and @code{path2/}
are (possibly different or empty) paths, @code{workfile}
is a filename, and @code{X} is an RCs suffix. If @code{X}
is empty, @code{path1/} must start with @code{RCS/} or
must contain @code{/RCS/}.
@item Only the RCS file is given. Then the working file is created
in the current directory and its name is derived from the name of
the RCS file by removing @code{path1/} and the suffix @code{X}.
@item Only the working file is given. Then @code{ci} considers each
RCS suffix @code{X} in turn, looking for an RCS file of the form
@code{path2/RCS/workfileX} or (if the former is not found and
@code{X} is nonempty) @code{path2/workfileX}.
@end enumerate
If the RCS file is specified without a path in 1) and 2),
@code{ci} looks for the RCS file first in the directory
@code{./RCS} and then in the current directory.
@code{ci} reports an error if an attempt to open an RCS file
fails for an unusual reason, even if the RCS file's pathname is
just one of several possibilities. For example, to suppress use
of RCS commands in a directory @code{d} , create a regular file
named @code{d/RCS} so that casual attempts to use RCS commands in
@code{d} fail because @code{d/RCS} is not a directory.
@c =============================================================================
@c ci -- check in RCS revsisions
@c EXAMPLES
@c -----------------------------------------------------------------------------
@node ciExamples,ciFileModes,ciFileNaming,CheckIn
@section Examples
Suppose @code{,v} is an RCS suffix and the current directory
contains a subdirectory @code{RCS} with an RCS file
@file{io.c,v}. Then each of the following commands check in a
copy of @file{io.c} into @file{RCS/io.c,v} as the latest
revision, removing @file{io.c}.
@example
@w{ci io.c}
@w{ci RCS/io.c,v}
@w{ci io.c,v}
@w{ci io.c RCS/io.c,v}
@w{ci io.c io.c,v}
@w{ci RCS/io.c,v io.c}
@w{ci io.c,v io.c}
@end example
Suppose instead that the empty suffix is an RCS suffix and the
current directory contains a subdirectory @code{RCS} with an RCS
file @code{io.c}. The each of the following commands checks in a
new revision.
@example
@w{ci io.c}
@w{ci RCS/io.c}
@w{ci io.c RCS/io.c}
@w{ci RCS/io.c io.c}
@end example
@c =============================================================================
@c ci -- check in RCS revsisions
@c File modes
@c -----------------------------------------------------------------------------
@node ciFileModes,ciFiles,ciExamples,CheckIn
@section File Modes
An RCS file created by @code{ci} inherits the read and execute
permissions from the working file. If the RCS file exists
already, @code{ci} preserves its read and execute permissions.
@code{ci} always turns off all write permissions of RCS files.
@c =============================================================================
@c ci -- check in RCS revsisions
@c Files
@c -----------------------------------------------------------------------------
@node ciFiles,setuid use,ciFileModes,CheckIn
@section Files
Temporary files are created in the directory containing the
working file, and also in the temporary directory (@xref{ciEnv}
under @ref{coEnv}). A semaphore file or files
are created in the directory containing the RCS file. With a
nonempty suffix, the semaphore names begin with the first
character of the suffix; therefore, do not specify an suffix
whose first character could be that of a working filename. With
an empty suffix, the semaphore names end with @code{_} so working
filenames should not end in @code{_}
@code{ci} never changes an RCS or working file. Normally,
@code{ci} unlinks the file and creates a new one; but instead of
breaking a chain of one or more symbolic links to an RCS file, it
unlinks the destination file instead. Therefore, @code{ci} breaks
any hard or symbolic links to any working file it changes; and
hard links to RCS files are ineffective, but symbolic links to
RCS files are preserved.
The effective user must be able to search and write the directory
containing the RCS file. Normally, the real user must be able to
read the RCS and working files and to search and write the
directory containing the working file; however, some older hosts
cannot easily switch between real and effective users, so on
these hosts the effective user is used for all accesses. The
effective user is the same as the real user unless your copies of
@code{ci} and @code{co} have setuid privileges. As described in
the next section, these privileges yield extra security if the
effective user owns all RCS files and directories, and if only
the effective user can write RCS directories.
Users can control access to RCS files by setting the permissions
of the directory containing the files; only users with write
access to the directory can use RCS commands to change its RCS
files. For example, in hosts that allow a user to belong to
several groups, one can make a group's RCS directories writable
to that group only. This approach suffices for informal projects,
but it means that any group member can arbitrarily change the
group's RCS files, and can even remove them entirely. Hence more
formal projects sometimes distinguish between an RCS
administrator, who can change the RCS files at will, and other
project members, who can check in new revisions but cannot
otherwise change the RCS files.
@c =============================================================================
@c ci -- check in RCS revsisions
@c setuid use
@c -----------------------------------------------------------------------------
@node setuid use,ciEnv,ciFiles,CheckIn
@section Setuid use
To prevent anybody but their RCS administrator from deleting revisions,
a set of users can employ setuid privileges as follows.
@itemize @bullet{}
@item Check that the host supports RCS setuid use.
Consult a trustworthy expert if there are any doubts.
It is best if the @code{seteuid}
system call works as described in Posix 1003.1a Draft 5,
because RCS can switch back and forth easily
between real and effective users, even if the real user is
@code{root}.
If not, the second best is if the @code{setuid}
system call supports saved setuid
(the @code{_POSIX_SAVED_IDS} behavior of Posix 1003.1-1990);
this fails only if the real or effective user is
@code{root}.
If RCS detects any failure in setuid, it quits immediately.
@item Choose a user @code{A}
to serve as RCS administrator for the set of users.
Only @code{A} can invoke the @code{rcs}
command on the users' RCS files.
@code{A} should not be @code{root}
or any other user with special powers.
Mutually suspicious sets of users should use different administrators.
@item Choose a pathname @code{B} to be a directory of files to
be executed by the users.
@item Have @code{A} set up @code{B} to contain copies of
@code{ci} and @code{co} that are setuid to @code{A}
by copying the commands from their standard installation directory
@code{D} as follows:
@example
@group
mkdir @file{B}
cp @file{D}/c[io] @file{B}
chmod go-w,u+s @file{B}/c[io]
@end group
@end example
@item Have each user prepend @code{B} to their path as follows:
@example
@group
PATH=@file{B}:$PATH; export PATH # ordinary shell
set path=(@file{B} $path) # C - shell
@end group
@end example
@item Have @code{A} create each RCS directory @code{R}
with write access only to @code{A}
as follows:
@example
@group
mkdir @file{R}
chmod go-w @file{R}
@end group
@end example
@item If you want to let only certain users read the RCS files,
put the users into a group @code{G},
and have @code{A} further protect the RCs directory as follows:
@example
@group
chgrp @file{G} @file{R}
chmod g-w, o-rwx @file{R}
@end group
@end example
@item Have @code{A} copy old RCS files (if any) into
@code{R}, to ensure that @code{A} owns them.
@item An RCS file's access list limits who can check in and lock revisions.
The default access list is empty,
which grants checkin access to anyone who can read the RCS file.
If you want limit checkin access,
have @code{A} invoke @code{rcs -a} on the file; see @ref{rcs}
In particular, @code{rcs -e -a@file{A}} limits access to just
@code{A}.
@item Have @code{A} initialize any new RCS files with
@code{rcs -i} before initial checkin, adding the
@code{-a} option if you want to limit checkin access.
@item Give setuid privileges only to @code{ci}, @code{co},
and @code{rcsclean}; do not give them to @code{rcs}
or to any other command.
@item Do not use other setuid commands to invoke RCS commands;
setuid is trickier than you think!
@end itemize
@c =============================================================================
@c ci -- check in RCS revsisions
@c Environment
@c -----------------------------------------------------------------------------
@node ciEnv,ciDiag,setuid use,CheckIn
@section Environment
@table @code
@item RCSINIT
options prepended to the argument list, separated by spaces.
A backslash escapes spaces within an option.
The @code{RCSINIT} options are prepended to the argument lists
of most RCS commands. Useful @code{RCSINIT}
options include @code{-q}, @code{-V}, @code{-x} and @code{-z}.
@item TMPDIR
Name of the temporary directory.
If not set, the environment variables
@code{TMP} and @code{TEMP}
are inspected instead and the first value found is taken;
if none of them are set,
a host-dependent default is used, typically
@code{/tmp}.
@end table
@c =============================================================================
@c ci -- check in RCS revsisions
@c Diagnostics
@c -----------------------------------------------------------------------------
@node ciDiag,,ciEnv,CheckIn
@section Diagnostics
For each revision, @code{ci} prints the RCS file,
the working file, and the number of both the deposited and the
preceding revision. The exit status is zero if and only if all
operations were successful.
