ci - check in RCS revisions

     ci [ options ] file ...

     Ci stores new revisions into RCS files.  Each file name end-
     ing  in  `,v'  is  taken  to  be an RCS file, all others are
     assumed to be working files containing  new  revisions.   Ci
     deposits   the  contents  of  each  working  file  into  the
     corresponding RCS file.  If only a working file is given, ci
     tries  to  find  the corresponding RCS file in the directory
     ./RCS and then in the current directory.  For more  details,
     see the file naming section below.

     For 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, unless locking is set to strict  (see
     rcs(L)).  A lock held by someone else may be broken with the
     rcs command.

     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 -q is given) or  asks  whether
     to  abort  (if  -q is omitted). A deposit can be forced with
     the -f option.

     For each revision deposited, ci prompts for a  log  message.
     The log message should summarize the change and must be ter-
     minated with a line containing a single `.' or a  control-D.
     If  several  files  are checked in, ci asks whether to reuse
     the previous log message.  If the standard input  is  not  a
     terminal,  ci  suppresses  the  prompt and uses the same log
     message for all files.  See also -m.

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

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

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

               If rev is a revision number,  it  must  be  higher
               than  the  latest  one  on the branch to which rev
               belongs, or must start a new branch.

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

               If rev is omitted, 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 1.

               If rev is omitted and the caller has no lock,  but
               he is the owner of the file and locking is not set
               to strict, then the revision is  appended  to  the
               default  branch  (normally  the  trunk; see the -b
               option of rcs(L)).

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

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

     -k[rev]   searches the working file for  keyword  values  to
               determine  its  revision  number,  creation  date,
               state, and author (see co(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
               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 -r, -d,  -s,  -w,  and

     -l[rev]   works like -r, except it performs an additional 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.

     -u[rev]   works like -l, except that the deposited  revision
               is  not  locked.   This  is useful if one wants to
               process (e.g., compile) the  revision  immediately
               after checkin.

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

     -ddate    uses date for the checkin date and time.  Date may
               be specified in free format as explained in co(1).
               Useful for lying about the checkin date,  and  for
               -k if no date is available.

     -mmsg     uses the string msg as the  log  message  for  all
               revisions checked in.

     -nname    assigns the symbolic name name to  the  number  of
               the  checked-in revision.  Ci prints an error mes-
               sage  if  name  is  already  assigned  to  another

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

     -sstate   sets the state of the checked-in revision  to  the
               identifier state.  The default is Exp.

               writes descriptive text into the RCS file (deletes
               the  existing  text).   If  txtfile is omitted, ci
               prompts the user for text supplied from the  stan-
               dard  input,  terminated  with a line containing a
               single `.' or control-D.  Otherwise, the  descrip-
               tive text is copied from the file txtfile.  During
               initialization, descriptive text is requested even
               if  -t  is not given.  The prompt is suppressed if
               standard input is not a terminal.

     -wlogin   uses login for the author field of  the  deposited
               revision.   Useful for lying about the author, and
               for -k if no author is available.

     Pairs of RCS files and working files may be specified  in  3
     ways (see also the example section of co(1)).
     1) Both the RCS file and the working file are given. The RCS
     file  name  is  of the form path1/workfile,v and the working
     file name is of the form path2/workfile,  where  path1/  and
     path2/  are (possibly different or empty) paths and workfile
     is a file name.

     2) Only the RCS file is given.  Then  the  working  file  is
     assumed  to  be  in  the  current  directory and its name is
     derived from the name of the RCS file by removing path1/ and
     the suffix ,v.

     3) Only the working file is given. Then ci looks for an  RCS
     file  of  the  form path2/RCS/workfile,v or path2/workfile,v
     (in this order).

     If the RCS file is specified without a path in  1)  and  2),
     then  ci looks for the RCS file first in the directory ./RCS
     and then in the current directory.

     An RCS file created by ci inherits the read and execute per-
     missions  from  the  working  file.  If  the RCS file exists
     already, ci preserves its read and execute permissions.   Ci
     always turns off all write permissions of RCS files.

     The caller of the command must  have  read/write  permission
     for  the directories containing the RCS file and the working
     file, and read permission for the RCS file itself.  A number
     of temporary files are created.  A semaphore file is created
     in the directory containing the RCS file.  Ci always creates
     a new RCS file and unlinks the old one.  This strategy makes
     links to RCS files useless.

     For each revision, ci prints the RCS file, the working file,
     and the number of both the deposited and the preceding revi-
     sion.  The exit  status  always  refers  to  the  last  file
     checked in, and is 0 if the operation was successful, 1 oth-

     Author: Walter F. Tichy, Purdue University, West  Lafayette,
     IN, 47907.
     Revision Number: 1.4 ; Release Date: 89/10/30 .
     Copyright (C) 1982, 1988, 1989 by Walter F. Tichy.

     co(L),   ident(L),    rcs(L),    rcsdiff(L),    rcsintro(L),
     rcsmerge(L), rlog(L), rcsfile(L)
     Walter F. Tichy, "Design, Implementation, and Evaluation  of
     a  Revision  Control  System,"  in  Proceedings  of  the 6th
     International  Conference  on  Software  Engineering,  IEEE,
     Tokyo, Sept. 1982.