


CI(1)                                                       CI(1)


NNAAMMEE
       ci - check in RCS revisions

SSYYNNOOPPSSIISS
       ccii [_o_p_t_i_o_n_s] _f_i_l_e ...

DDEESSCCRRIIPPTTIIOONN
       ccii  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.  ccii deposits the contents of each working  file
       into  the  corresponding RCS file.  If only a working file
       is given, ccii tries to find the corresponding RCS  file  in
       an  RCS subdirectory and then in the working file's direc-
       tory.  For more details, see FILE NAMING below.

       For ccii 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 rrccss(1)).  A lock held by someone else may be
       broken with the rrccss command.

       Unless the --ff option is given, ccii checks whether the revi-
       sion  to  be deposited differs from the preceding one.  If
       not, instead of creating a new revision ccii reverts to  the
       preceding one.  To revert, ordinary ccii removes the working
       file and any lock; ccii --ll keeps and ccii --uu removes any lock,
       and  then they both generate a new working file much as if
       ccoo --ll or ccoo --uu had been applied to the preceding revision.
       When reverting, any --nn and --ss options apply to the preced-
       ing revision.

       For each revision deposited, ccii 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  .. by
       itself.   If  several files are checked in ccii asks whether
       to reuse the previous log message.  If the standard  input
       is  not  a terminal, ccii suppresses the prompt and uses the
       same log message for all files.  See also --mm.

       If the RCS file does not exist, ccii creates it and deposits
       the  contents  of the working file as the initial revision
       (default number: 11..11).  The access list is initialized  to
       empty.   Instead  of the log message, ccii requests descrip-
       tive text (see --tt below).

       The number _r_e_v of the deposited revision can be  given  by
       any of the options --ff, --II, --kk, --ll, --MM, --qq, --rr, or --uu.  _r_e_v
       may be symbolic, numeric, or  mixed.   If  _r_e_v  is  $$,  ccii
       determines  the revision number from keyword values in the



GNU                         1991/10/07                          1





CI(1)                                                       CI(1)


       working file.

       If _r_e_v is a revision number, it must be  higher  than  the
       latest  one  on  the  branch to which _r_e_v belongs, or must
       start a new branch.

       If _r_e_v 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  _r_e_v  indicates  a  non-existing branch, that
       branch is  created  with  the  initial  revision  numbered
       _r_e_v..11.

       If  _r_e_v  is  omitted,  ccii 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 11.

       If _r_e_v is omitted and the caller has no lock, but owns the
       file and locking is not set to _s_t_r_i_c_t, then  the  revision
       is appended to the default branch (normally the trunk; see
       the --bb option of rrccss(1)).

       Exception: On the trunk, revisions can be appended to  the
       end, but not inserted.

OOPPTTIIOONNSS
       --rr[_r_e_v]
              checks  in  a  revision, releases the corresponding
              lock, and removes the working file.   This  is  the
              default.

              The  --rr  option  has  an unusual meaning in ccii.  In
              other RCS commands, --rr merely specifies a  revision
              number,  but  in  ccii  it  also  releases a lock and
              removes the working file.   See  --uu  for  a  tricky
              example.

       --ll[_r_e_v]
              works  like  --rr,  except  it performs an additional
              ccoo --l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.

       --uu[_r_e_v]
              works like --ll, except that the  deposited  revision
              is not locked.  This lets one read the working file



GNU                         1991/10/07                          2





CI(1)                                                       CI(1)


              immediately after checkin.

              The --ll, --rr, and --uu options are  mutually  exclusive
              and  silently  override  each  other.  For example,
              ccii --uu --rr is equivalent to ccii --rr  because  --rr  over-
              rides --uu.

       --ff[_r_e_v]
              forces  a  deposit;  the  new revision is deposited
              even it is not different from the preceding one.

       --kk[_r_e_v]
              searches the working file  for  keyword  values  to
              determine   its  revision  number,  creation  date,
              state, and author (see ccoo(1)),  and  assigns  these
              values  to the deposited revision, rather than com-
              puting 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  --kk
              option at these sites to preserve the original num-
              ber, date, author, and state.  The  extracted  key-
              word  values  and  the  default  log message may be
              overridden with the options --dd, --mm, --ss, --ww, and any
              option that carries a revision number.

       --qq[_r_e_v]
              quiet  mode;  diagnostic  output is not printed.  A
              revision that is not different from  the  preceding
              one is not deposited, unless --ff is given.

       --II[_r_e_v]
              interactive  mode;  the  user is prompted and ques-
              tioned even if the standard input is not  a  termi-
              nal.

       --dd[_d_a_t_e]
              uses  _d_a_t_e for the checkin date and time.  The _d_a_t_e
              is specified in free format as explained in  ccoo(1).
              This  is  useful  for lying about the checkin date,
              and for --kk if no date is  available.   If  _d_a_t_e  is
              empty, the working file's time of last modification
              is used.

       --MM[_r_e_v]
              Set the modification time on any new  working  file
              to  be  the  date  of  the retrieved revision.  For
              example, ccii --dd --MM --uu _f does not alter _f's modifica-
              tion  time, even if _f's contents change due to key-
              word substitution.  Use this option with  care;  it
              can confuse mmaakkee(1).

       --mm_m_s_g  uses  the  string  _m_s_g  as  the log message for all



GNU                         1991/10/07                          3





CI(1)                                                       CI(1)


              revisions checked in.

       --nn_n_a_m_e assigns the symbolic name _n_a_m_e to the number of the
              checked-in revision.  ccii prints an error message if
              _n_a_m_e is already assigned to another number.

       --NN_n_a_m_e same as --nn, except that  it  overrides  a  previous
              assignment of _n_a_m_e.

       --ss_s_t_a_t_e
              sets  the  state  of the checked-in revision to the
              identifier _s_t_a_t_e.  The default state is EExxpp.

       --tt_f_i_l_e writes descriptive text from the  contents  of  the
              named _f_i_l_e into the RCS file, deleting the existing
              text.  The _f_i_l_e may not begin with --.

       --tt--_s_t_r_i_n_g
              Write descriptive text from the _s_t_r_i_n_g into the RCS
              file, deleting the existing text.

              The  --tt  option, in both its forms, has effect only
              during an initial checkin; it is  silently  ignored
              otherwise.

              During  the initial checkin, if --tt is not given, ccii
              obtains the text from standard input, terminated by
              end-of-file  or  by  a line containing .. by itself.
              The user is prompted for the text if interaction is
              possible; see --II.

              For  backward  compatibility with older versions of
              RCS, a bare --tt option is ignored.

       --ww_l_o_g_i_n
              uses _l_o_g_i_n for the author field  of  the  deposited
              revision.   Useful  for lying about the author, and
              for --kk if no author is available.

       --VV_n    Emulate RCS version _n.  See ccoo(1) for details.

       --xx_s_u_f_f_i_x_e_s
              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
              RRCCSS//_f_i_l_e or _p_a_t_h//RRCCSS//_f_i_l_e_.  The --xx option can spec-
              ify a list of suffixes separated by //.   For  exam-
              ple, --xx,,vv// specifies two suffixes: ,,v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



GNU                         1991/10/07                          4





CI(1)                                                       CI(1)


              _s_u_f_f_i_x_e_s is installation-dependent; normally it  is
              ,,vv//  for hosts like Unix that permit commas in file
              names, and is empty (i.e. just  the  empty  suffix)
              for other hosts.

FFIILLEE NNAAMMIINNGG
       Pairs  of  RCS files and working files may be specified in
       three ways (see also the example section).

       1) Both the RCS file and the working file are given.   The
       RCS  pathname is of the form _p_a_t_h_1//_w_o_r_k_f_i_l_e_X and the work-
       ing pathname is of the form  _p_a_t_h_2//_w_o_r_k_f_i_l_e  where  _p_a_t_h_1//
       and  _p_a_t_h_2// are (possibly different or empty) paths, _w_o_r_k_-
       _f_i_l_e is a filename, and _X is  an  RCS  suffix.   If  _X  is
       empty, _p_a_t_h_1// must be RRCCSS// or must end in //RRCCSS//.

       2)  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 _p_a_t_h_1// and the
       suffix _X.

       3) Only the working file is given.  Then ccii considers each
       RCS  suffix _X in turn, looking for an RCS file of the form
       _p_a_t_h_2//RRCCSS//_w_o_r_k_f_i_l_e_X or (if the former is not found  and  _X
       is nonempty) _p_a_t_h_2//_w_o_r_k_f_i_l_e_X_.

       If  the RCS file is specified without a path in 1) and 2),
       ccii looks for the RCS file first in the directory ..//RRCCSS and
       then in the current directory.

       ccii  reports  an  error  if  an attempt to open an RCS file
       fails for an unusual reason, even if the RCS file's  path-
       name  is  just one of several possibilities.  For example,
       to suppress use of RCS commands in a directory _d, create a
       regular  file  named  _d//RRCCSS so that casual attempts to use
       RCS commands in _d fail because _d//RRCCSS is not a directory.

EEXXAAMMPPLLEESS
       Suppose ,,vv is an RCS suffix and the current directory con-
       tains  a  subdirectory  RRCCSS with an RCS file iioo..cc,,vv.  Then
       each of the following commands check in  a  copy  of  iioo..cc
       into RRCCSS//iioo..cc,,vv as the latest revision, removing iioo..cc.

              ccii  iioo..cc;;    ccii  RRCCSS//iioo..cc,,vv;;   ccii  iioo..cc,,vv;;
              ccii  iioo..cc  RRCCSS//iioo..cc,,vv;;    ccii  iioo..cc  iioo..cc,,vv;;
              ccii  RRCCSS//iioo..cc,,vv  iioo..cc;;    ccii  iioo..cc,,vv  iioo..cc;;

       Suppose instead that the empty suffix is an RCS suffix and
       the current directory contains a subdirectory RRCCSS with  an
       RCS  file iioo..cc.  The each of the following commands checks
       in a new revision.

              ccii  iioo..cc;;    ccii  RRCCSS//iioo..cc;;
              ccii  iioo..cc  RRCCSS//iioo..cc;;



GNU                         1991/10/07                          5





CI(1)                                                       CI(1)


              ccii  RRCCSS//iioo..cc  iioo..cc;;

FFIILLEE MMOODDEESS
       An RCS file created by ccii inherits the  read  and  execute
       permissions from the working file.  If the RCS file exists
       already, ccii preserves its read  and  execute  permissions.
       ccii always turns off all write permissions of RCS files.

FFIILLEESS
       Several  temporary  files  may be created in the directory
       containing the working file, and  also  in  the  temporary
       directory  (see  TTMMPPDDIIRR  under  EENNVVIIRROONNMMEENNTT).  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 __ so working filenames should not
       end in __.

       ccii never changes an RCS or  working  file.   Normally,  ccii
       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,
       ccii 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 ccii
       and ccoo 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 per-
       missions 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 for-
       mal projects sometimes distinguish between an RCS adminis-
       trator,  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.



GNU                         1991/10/07                          6





CI(1)                                                       CI(1)


SSEETTUUIIDD UUSSEE
       To prevent anybody but their RCS administrator from delet-
       ing revisions, a set of users can employ setuid privileges
       as follows.

       +o Check  that the host supports RCS setuid use.  Consult a
         trustworthy expert if there are any doubts.  It is  best
         if the sseetteeuuiidd(()) 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 rroooott.  If not, the second best  is  if  the
         sseettuuiidd(())   system   call   supports  saved  setuid  (the
         {_POSIX_SAVED_IDS} behavior of Posix 1003.1-1990);  this
         fails only if the real user is rroooott.  If RCS detects any
         failure in setuid, it quits immediately.

       +o Choose a user _A to serve as RCS  administrator  for  the
         set  of  users.   Only  _A will be able to invoke the rrccss
         command on the users' RCS files.  _A should not  be  rroooott
         or  any other user with special powers.  Mutually suspi-
         cious sets of users should use different administrators.

       +o Choose  a  path name _B that will be a directory of files
         to be executed by the users.

       +o Have _A set up _B to contain copies of ccii and ccoo that  are
         setuid  to _A by copying the commands from their standard
         installation directory _D as follows:

              mmkkddiirr  _B
              ccpp  _D//cc[[iioo]]  _B
              cchhmmoodd  ggoo--ww,,uu++ss  _B//cc[[iioo]]

       +o Have each user prepend _B to their path as follows:

              PPAATTHH==_B::$$PPAATTHH;;  eexxppoorrtt  PPAATTHH  # ordinary shell
              sseett  ppaatthh==((_B  $$ppaatthh))  # C shell

       +o Have _A create each RCS directory  _R  with  write  access
         only to _A as follows:

              mmkkddiirr  _R
              cchhmmoodd  ggoo--ww  _R

       +o If  you  want  to  let  only  certain users read the RCS
         files, put the users into a group _G, and have _A  further
         protect the RCS directory as follows:

              cchhggrrpp  _G  _R
              cchhmmoodd  gg--ww,,oo--rrwwxx  _R

       +o Have  _A  copy  old  RCS files (if any) into _R, to ensure
         that _A owns them.




GNU                         1991/10/07                          7





CI(1)                                                       CI(1)


       +o 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 _A invoke
         rrccss --aa  on  the  file;  see  rrccss(1).    In   particular,
         rrccss --ee --aa_A limits access to just _A.

       +o Have  _A  initialize any new RCS files with rrccss --ii before
         initial checkin, adding the --aa option  if  you  want  to
         limit checkin access.

       +o Give  setuid privileges only to ccii, ccoo, and rrccsscclleeaann; do
         not give them to rrccss or to any other command.

       +o Do not use other setuid commands to invoke RCS commands;
         setuid is trickier than you think!

EENNVVIIRROONNMMEENNTT
       RRCCSSIINNIITT
              options  prepended  to the argument list, separated
              by spaces.  A backslash escapes  spaces  within  an
              option.   The  RRCCSSIINNIITT options are prepended to the
              argument  lists  of  most  RCS  commands.    Useful
              RRCCSSIINNIITT options include --qq, --VV, and --xx.

       TTMMPPDDIIRR Name  of  the temporary directory.  If not set, the
              environment variables TTMMPP and  TTEEMMPP  are  inspected
              instead and the first value found is taken; if none
              of them are set, a host-dependent default is  used,
              typically //ttmmpp.

DDIIAAGGNNOOSSTTIICCSS
       For  each  revision,  ccii  prints the RCS file, the working
       file, and the number of both the deposited and the preced-
       ing  revision.  The exit status is zero if and only if all
       operations were successful.

IIDDEENNTTIIFFIICCAATTIIOONN
       Author: Walter F. Tichy.
       Revision Number: 5.9; Release Date: 1991/10/07.
       Copyright (C) 1982, 1988, 1989 by Walter F. Tichy.
       Copyright (C) 1990, 1991 by Paul Eggert.

SSEEEE AALLSSOO
       co(1), ident(1), make(1), rcs(1), rcsclean(1), rcsdiff(1),
       rcsintro(1), rcsmerge(1), rlog(1), rcsfile(5)
       Walter  F.  Tichy,  RCS--A  System  for  Version  Control,
       _S_o_f_t_w_a_r_e_-_-_P_r_a_c_t_i_c_e  _&  _E_x_p_e_r_i_e_n_c_e  1155,  7   (July   1985),
       637-654.








GNU                         1991/10/07                          8


