home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / RCS43X.ZIP / CI.MAN < prev    next >
Text File  |  1990-11-19  |  10KB  |  212 lines
  1. NAME
  2.      ci - check in RCS revisions
  3.  
  4. SYNOPSIS
  5.      ci [ options ] file ...
  6.  
  7. DESCRIPTION
  8.      Ci stores new revisions into RCS files.  Each file name end-
  9.      ing in `,v' is taken to be an RCS file, all others are
  10.      assumed to be working files containing new revisions.  Ci
  11.      deposits the contents of each working file into the
  12.      corresponding RCS file.  If only a working file is given, ci
  13.      tries to find the corresponding RCS file in the directory
  14.      ./RCS and then in the current directory.  For more details,
  15.      see the file naming section below.
  16.  
  17.      For ci to work, the caller's login must be on the access
  18.      list, except if the access list is empty or the caller is
  19.      the superuser or the owner of the file.  To append a new
  20.      revision to an existing branch, the tip revision on that
  21.      branch must be locked by the caller. Otherwise, only a new
  22.      branch can be created. This restriction is not enforced for
  23.      the owner of the file, unless locking is set to strict (see
  24.      rcs(L)).  A lock held by someone else may be broken with the
  25.      rcs command.
  26.  
  27.      Normally, ci checks whether the revision to be deposited is
  28.      different from the preceding one. If it is not different, ci
  29.      either aborts the deposit (if -q is given) or asks whether
  30.      to abort (if -q is omitted). A deposit can be forced with
  31.      the -f option.
  32.  
  33.      For each revision deposited, ci prompts for a log message.
  34.      The log message should summarize the change and must be ter-
  35.      minated with a line containing a single `.' or a control-D.
  36.      If several files are checked in, ci asks whether to reuse
  37.      the previous log message.  If the standard input is not a
  38.      terminal, ci suppresses the prompt and uses the same log
  39.      message for all files.  See also -m.
  40.  
  41.      The number of the deposited revision can be given by any of
  42.      the options -r, -f, -k, -l, -u, or -q.
  43.  
  44.      If the RCS file does not exist, ci creates it and deposits
  45.      the contents of the working file as the initial revision
  46.      (default number: 1.1).  The access list is initialized to
  47.      empty.  Instead of the log message, ci requests descriptive
  48.      text (see -t below).
  49.  
  50.      -r[rev]   assigns the revision number rev to the checked-in
  51.                revision, releases the corresponding lock, and
  52.                deletes the working file. This is the default.
  53.                Rev may be symbolic, numeric, or mixed.
  54.  
  55.                If rev is a revision number, it must be higher
  56.                than the latest one on the branch to which rev
  57.                belongs, or must start a new branch.
  58.  
  59.                If rev is a branch rather than a revision number,
  60.                the new revision is appended to that branch. The
  61.                level number is obtained by incrementing the tip
  62.                revision number of that branch.  If rev indicates
  63.                a non-existing branch, that branch is created with
  64.                the initial revision numbered rev.1.
  65.  
  66.                If rev is omitted, ci tries to derive the new
  67.                revision number from the caller's last lock. If
  68.                the caller has locked the tip revision of a
  69.                branch, the new revision is appended to that
  70.                branch. The new revision number is obtained by
  71.                incrementing the tip revision number.  If the
  72.                caller locked a non-tip revision, a new branch is
  73.                started at that revision by incrementing the
  74.                highest branch number at that revision.  The
  75.                default initial branch and level numbers are 1.
  76.  
  77.                If rev is omitted and the caller has no lock, but
  78.                he is the owner of the file and locking is not set
  79.                to strict, then the revision is appended to the
  80.                default branch (normally the trunk; see the -b
  81.                option of rcs(L)).
  82.  
  83.                Exception: On the trunk, revisions can be appended
  84.                to the end, but not inserted.
  85.  
  86.      -f[rev]   forces a deposit; the new revision is deposited
  87.                even it is not different from the preceding one.
  88.  
  89.      -k[rev]   searches the working file for keyword values to
  90.                determine its revision number, creation date,
  91.                state, and author (see co(1)), and assigns these
  92.                values to the deposited revision, rather than com-
  93.                puting them locally.  It also generates a default
  94.                login message noting the login of the caller and
  95.                the actual checkin date.  This option is useful
  96.                for software distribution. A revision that is sent
  97.                to several sites should be checked in with the -k
  98.                option at these sites to preserve the original
  99.                number, date, author, and state.  The extracted
  100.                keyword values and the default log message may be
  101.                overridden with the options -r, -d, -s, -w, and
  102.                -m.
  103.  
  104.      -l[rev]   works like -r, except it performs an additional co
  105.                -l for the deposited revision. Thus, the deposited
  106.                revision is immediately checked out again and
  107.                locked.  This is useful for saving a revision
  108.                although one wants to continue editing it after
  109.                the checkin.
  110.  
  111.      -u[rev]   works like -l, except that the deposited revision
  112.                is not locked.  This is useful if one wants to
  113.                process (e.g., compile) the revision immediately
  114.                after checkin.
  115.  
  116.      -q[rev]   quiet mode; diagnostic output is not printed.  A
  117.                revision that is not different from the preceding
  118.                one is not deposited, unless -f is given.
  119.  
  120.      -ddate    uses date for the checkin date and time.  Date may
  121.                be specified in free format as explained in co(1).
  122.                Useful for lying about the checkin date, and for
  123.                -k if no date is available.
  124.  
  125.      -mmsg     uses the string msg as the log message for all
  126.                revisions checked in.
  127.  
  128.      -nname    assigns the symbolic name name to the number of
  129.                the checked-in revision.  Ci prints an error mes-
  130.                sage if name is already assigned to another
  131.                number.
  132.  
  133.      -Nname    same as -n, except that it overrides a previous
  134.                assignment of name.
  135.  
  136.      -sstate   sets the state of the checked-in revision to the
  137.                identifier state.  The default is Exp.
  138.  
  139.      -t[txtfile]
  140.                writes descriptive text into the RCS file (deletes
  141.                the existing text).  If txtfile is omitted, ci
  142.                prompts the user for text supplied from the stan-
  143.                dard input, terminated with a line containing a
  144.                single `.' or control-D.  Otherwise, the descrip-
  145.                tive text is copied from the file txtfile.  During
  146.                initialization, descriptive text is requested even
  147.                if -t is not given.  The prompt is suppressed if
  148.                standard input is not a terminal.
  149.  
  150.      -wlogin   uses login for the author field of the deposited
  151.                revision.  Useful for lying about the author, and
  152.                for -k if no author is available.
  153.  
  154. FILE NAMING
  155.      Pairs of RCS files and working files may be specified in 3
  156.      ways (see also the example section of co(1)).
  157.  
  158.      1) Both the RCS file and the working file are given. The RCS
  159.      file name is of the form path1/workfile,v and the working
  160.      file name is of the form path2/workfile, where path1/ and
  161.      path2/ are (possibly different or empty) paths and workfile
  162.      is a file name.
  163.  
  164.      2) Only the RCS file is given. Then the working file is
  165.      assumed to be in the current directory and its name is
  166.      derived from the name of the RCS file by removing path1/ and
  167.      the suffix ,v.
  168.  
  169.      3) Only the working file is given. Then ci looks for an RCS
  170.      file of the form path2/RCS/workfile,v or path2/workfile,v
  171.      (in this order).
  172.  
  173.      If the RCS file is specified without a path in 1) and 2),
  174.      then ci looks for the RCS file first in the directory ./RCS
  175.      and then in the current directory.
  176.  
  177. FILE MODES
  178.      An RCS file created by ci inherits the read and execute per-
  179.      missions from the working file. If the RCS file exists
  180.      already, ci preserves its read and execute permissions.  Ci
  181.      always turns off all write permissions of RCS files.
  182.  
  183. FILES
  184.      The caller of the command must have read/write permission
  185.      for the directories containing the RCS file and the working
  186.      file, and read permission for the RCS file itself.  A number
  187.      of temporary files are created.  A semaphore file is created
  188.      in the directory containing the RCS file.  Ci always creates
  189.      a new RCS file and unlinks the old one.  This strategy makes
  190.      links to RCS files useless.
  191.  
  192. DIAGNOSTICS
  193.      For each revision, ci prints the RCS file, the working file,
  194.      and the number of both the deposited and the preceding revi-
  195.      sion.  The exit status always refers to the last file
  196.      checked in, and is 0 if the operation was successful, 1 oth-
  197.      erwise.
  198.  
  199. IDENTIFICATION
  200.      Author: Walter F. Tichy, Purdue University, West Lafayette,
  201.      IN, 47907.
  202.      Revision Number: 1.4 ; Release Date: 89/10/30 .
  203.      Copyright c 1982, 1988, 1989 by Walter F. Tichy.
  204.  
  205. SEE ALSO
  206.      co(L), ident(L), rcs(L), rcsdiff(L), rcsintro(L),
  207.      rcsmerge(L), rlog(L), rcsfile(L)
  208.      Walter F. Tichy, "Design, Implementation, and Evaluation of
  209.      a Revision Control System," in Proceedings of the 6th Inter-
  210.      national Conference on Software Engineering, IEEE, Tokyo,
  211.      Sept. 1982.
  212.