

CI(1)                      Unix Programmer's Manual                      CI(1)


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

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

DDDEEESSSCCCRRRIIIPPPTTTIIIOOONNN
     ccciii stores new revisions into RCS files.  Each file name ending in  ,,,vvv  is
     taken  to  be  an  RCS  file.  All others are assumed to be working files
     containing new revisions.  ccciii deposits the contents of each working  file
     into  the  corresponding  RCS  file.  If only a working file is given, ccciii
     tries to find the corresponding RCS file in an RCS subdirectory and  then
     in  the  working  file's  directory.   For  more details, see FILE NAMING
     below.

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

     Normally, ccciii checks whether the revision to  be  deposited  is  different
     from  the  preceding one.  If it is not different, ccciii aborts the deposit,
     asking beforehand if possible.  A deposit  can  be  forced  with  the  ---fff
     option.

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

     The number of the deposited revision can be given by any of  the  options
     ---fff, ---III, ---kkk, ---lll, ---qqq, ---rrr, or ---uuu.

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

OOOPPPTTTIIIOOONNNSSS

     ---rrr[rev]]]
          assigns the revision number _r_e_v to the checked-in revision, releases
          the  corresponding  lock, and deletes the working file.  This is the
          default.  _r_e_v may be symbolic, numeric, or mixed.

     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


                                    \*(Dt                                    1



CI(1)                      Unix Programmer's Manual                      CI(1)


     branch, that branch is created with the initial revision numbered _r_e_v...111...

     If _r_e_v is omitted, cccii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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b option of rrrcccsss(1)).

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

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

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

     ---lll[rev]]]
          works like ---rrr, except it performs  an  additional  cccooo\\\  ---l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u[rev]]]
          works like ---lll, except that the deposited  revision  is  not  locked.
          This lets one read the working file immediately after checkin.

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

     ---III[rev]]]
          interactive mode; the user is prompted and questioned  even  if  the
          standard input is not a terminal.

     ---ddd[date]]]
          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ccooo(1).  This is useful for lying about


                                    \*(Dt                                    2



CI(1)                      Unix Programmer's Manual                      CI(1)


          the checkin date, and for ---k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m_m_s_g
          uses the string _m_s_g as the log message for all revisions checked in.

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

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

     ---s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EExxxppp.

     ---t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 name may not begin
          with ---.

     ---t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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t is not given, cccii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I.

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

     ---w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k if no author is available.

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

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

     1) Both the RCS file and the working file are given.  The RCS  file  name
     is  of the form _p_a_t_h_1///_w_o_r_k_f_i_l_e,,,vvv and the working file name 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 and _w_o_r_k_f_i_l_e is a file name.

     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 ,,,vvv.


                                    \*(Dt                                    3



CI(1)                      Unix Programmer's Manual                      CI(1)


     3) Only the working file is given.  Then ccciii looks for an RCS file of  the
     form _p_a_t_h_2///RRRCCCSSS///_w_o_r_k_f_i_l_e,,,vvv or _p_a_t_h_2///_w_o_r_k_f_i_l_e,,,vvv (in this order).

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

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

FFFIIILLLEEESSS
     Several temporary files may be created.  A semaphore file is  created  in
     the  directory containing the RCS file.  The effective user+group must be
     able to read  the  RCS  file  and  to  search  and  write  the  directory
     containing  the  RCS file.  Normally, the real user+group must be able to
     read the working file and to search and write  the  directory  containing
     the  working file; however, some older hosts that do not conform to Posix
     1003.1-1990 cannot easily switch between real and effective  ids,  so  on
     these  hosts  the  effective  user+group  is  used for all accesses.  The
     effective user+group is the same as the real user+group unless your  copy
     of  RCS  has  setuid  or setgid privileges.  These privileges yield extra
     security if RCS files are protected so that only the effective user+group
     can  write  RCS  directories.   Further  protection  can  be  achieved by
     granting access only to the effective user+group.

     ccciii never changes an RCS or working file; instead, it unlinks the file and
     creates  a  new  one.  This strategy breaks hard links to such files, but
     does not affect symbolic links.

DDDIIIAAAGGGNNNOOOSSSTTTIIICCCSSS
     For each revision, ccciii 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.

IIIDDDEEENNNTTTIIIFFFIIICCCAAATTTIIIOOONNN
     Author: Walter F. Tichy.
     Revision Number: 5.4; Release Date: 1990/12/04.
     Copyright (c) 1982, 1988, 1989 by Walter F. Tichy.
     Copyright (c) 1990 by Paul Eggert.

SSSEEEEEE AAALLLSSSOOO
     co(1), ident(1), rcs(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11555, 7 (July 1985), 637-654.










                                    \*(Dt                                    4

