home *** CD-ROM | disk | FTP | other *** search
/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / zip / gnu / rcs5ap1b.lzh / RCS5AP1B / CI.1LP next >
Text File  |  1991-01-30  |  12KB  |  331 lines
  1.  
  2.  
  3.  
  4. CI(1)                  Programmer's Manual                  CI(1)
  5.  
  6.  
  7.  
  8. NAME
  9.      ci - check in RCS revisions
  10.  
  11. SYNOPSIS
  12.      ci [_✓o_✓p_✓t_✓i_✓o_✓n_✓s] _✓f_✓i_✓l_✓e ...
  13.  
  14. DESCRIPTION
  15.      ci stores new revisions into RCS files.  Each file name end-
  16.      ing in ,v is taken to be an RCS file.  All others are
  17.      assumed to be working files containing new revisions.  ci
  18.      deposits the contents of each working file into the
  19.      corresponding RCS file.  If only a working file is given, ci
  20.      tries to find the corresponding RCS file in an RCS subdirec-
  21.      tory and then in the working file's directory.  For more
  22.      details, see FILE NAMING below.
  23.  
  24.      For ci to work, the caller's login must be on the access
  25.      list, except if the access list is empty or the caller is
  26.      the superuser or the owner of the file.  To append a new
  27.      revision to an existing branch, the tip revision on that
  28.      branch must be locked by the caller.  Otherwise, only a new
  29.      branch can be created.  This restriction is not enforced for
  30.      the owner of the file if non-strict locking is used (see
  31.      rcs(1)).  A lock held by someone else may be broken with the
  32.      rcs command.
  33.  
  34.      Normally, ci checks whether the revision to be deposited is
  35.      different from the preceding one.  If it is not different,
  36.      ci aborts the deposit, asking beforehand if possible.  A
  37.      deposit can be forced with the -f option.
  38.  
  39.      For each revision deposited, ci prompts for a log message.
  40.      The log message should summarize the change and must be ter-
  41.      minated by end-of-file or by a line containing . by itself.
  42.      If several files are checked in ci asks whether to reuse the
  43.      previous log message.  If the standard input is not a termi-
  44.      nal, ci suppresses the prompt and uses the same log message
  45.      for all files.  See also -m.
  46.  
  47.      The number of the deposited revision can be given by any of
  48.      the options -f, -I, -k, -l, -q, -r, or -u.
  49.  
  50.      If the RCS file does not exist, ci creates it and deposits
  51.      the contents of the working file as the initial revision
  52.      (default number: 1.1).  The access list is initialized to
  53.      empty.  Instead of the log message, ci requests descriptive
  54.      text (see -t below).
  55.  
  56. OPTIONS
  57.      -r[_✓r_✓e_✓v]
  58.           assigns the revision number _✓r_✓e_✓v to the checked-in revi-
  59.           sion, releases the corresponding lock, and deletes the
  60.  
  61.  
  62.  
  63. Printed 1/29/91            1990/12/04                           1
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. CI(1)                  Programmer's Manual                  CI(1)
  71.  
  72.  
  73.  
  74.           working file.  This is the default.  _✓r_✓e_✓v may be sym-
  75.           bolic, numeric, or mixed.
  76.  
  77.           If _✓r_✓e_✓v is a revision number, it must be higher than the
  78.           latest one on the branch to which _✓r_✓e_✓v belongs, or must
  79.           start a new branch.
  80.  
  81.           If _✓r_✓e_✓v is a branch rather than a revision number, the
  82.           new revision is appended to that branch.  The level
  83.           number is obtained by incrementing the tip revision
  84.           number of that branch.  If _✓r_✓e_✓v indicates a non-existing
  85.           branch, that branch is created with the initial revi-
  86.           sion numbered _✓r_✓e_✓v.1.
  87.  
  88.           If _✓r_✓e_✓v is omitted, ci tries to derive the new revision
  89.           number from the caller's last lock.  If the caller has
  90.           locked the tip revision of a branch, the new revision
  91.           is appended to that branch.  The new revision number is
  92.           obtained by incrementing the tip revision number.  If
  93.           the caller locked a non-tip revision, a new branch is
  94.           started at that revision by incrementing the highest
  95.           branch number at that revision.  The default initial
  96.           branch and level numbers are 1.
  97.  
  98.           If _✓r_✓e_✓v is omitted and the caller has no lock, but owns
  99.           the file and locking is not set to _✓s_✓t_✓r_✓i_✓c_✓t, then the
  100.           revision is appended to the default branch (normally
  101.           the trunk; see the -b option of rcs(1)).
  102.  
  103.           Exception: On the trunk, revisions can be appended to
  104.           the end, but not inserted.
  105.  
  106.      -f[_✓r_✓e_✓v]
  107.           forces a deposit; the new revision is deposited even it
  108.           is not different from the preceding one.
  109.  
  110.      -k[_✓r_✓e_✓v]
  111.           searches the working file for keyword values to deter-
  112.           mine its revision number, creation date, state, and
  113.           author (see co(1)), and assigns these values to the
  114.           deposited revision, rather than computing them locally.
  115.           It also generates a default login message noting the
  116.           login of the caller and the actual checkin date.  This
  117.           option is useful for software distribution.  A revision
  118.           that is sent to several sites should be checked in with
  119.           the -k option at these sites to preserve the original
  120.           number, date, author, and state.  The extracted keyword
  121.           values and the default log message may be overridden
  122.           with the options -d, -m, -s, -w, and any option that
  123.           carries a revision number.
  124.  
  125.      -l[_✓r_✓e_✓v]
  126.  
  127.  
  128.  
  129. Printed 1/29/91            1990/12/04                           2
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. CI(1)                  Programmer's Manual                  CI(1)
  137.  
  138.  
  139.  
  140.           works like -r, except it performs an additional co -l
  141.           for the deposited revision.  Thus, the deposited revi-
  142.           sion is immediately checked out again and locked.  This
  143.           is useful for saving a revision although one wants to
  144.           continue editing it after the checkin.
  145.  
  146.      -u[_✓r_✓e_✓v]
  147.           works like -l, except that the deposited revision is
  148.           not locked.  This lets one read the working file
  149.           immediately after checkin.
  150.  
  151.      -q[_✓r_✓e_✓v]
  152.           quiet mode; diagnostic output is not printed.  A revi-
  153.           sion that is not different from the preceding one is
  154.           not deposited, unless -f is given.
  155.  
  156.      -I[_✓r_✓e_✓v]
  157.           interactive mode; the user is prompted and questioned
  158.           even if the standard input is not a terminal.
  159.  
  160.      -d[_✓d_✓a_✓t_✓e]
  161.           uses _✓d_✓a_✓t_✓e for the checkin date and time.  The _✓d_✓a_✓t_✓e is
  162.           specified in free format as explained in co(1).  This
  163.           is useful for lying about the checkin date, and for -k
  164.           if no date is available.  If _✓d_✓a_✓t_✓e is empty, the working
  165.           file's time of last modification is used.
  166.  
  167.      -m_✓m_✓s_✓g
  168.           uses the string _✓m_✓s_✓g as the log message for all revi-
  169.           sions checked in.
  170.  
  171.      -n_✓n_✓a_✓m_✓e
  172.           assigns the symbolic name _✓n_✓a_✓m_✓e to the number of the
  173.           checked-in revision.  ci prints an error message if
  174.           _✓n_✓a_✓m_✓e is already assigned to another number.
  175.  
  176.      -N_✓n_✓a_✓m_✓e
  177.           same as -n, except that it overrides a previous assign-
  178.           ment of _✓n_✓a_✓m_✓e.
  179.  
  180.      -s_✓s_✓t_✓a_✓t_✓e
  181.           sets the state of the checked-in revision to the iden-
  182.           tifier _✓s_✓t_✓a_✓t_✓e.  The default state is Exp.
  183.  
  184.      -t_✓f_✓i_✓l_✓e
  185.           writes descriptive text from the contents of the named
  186.           _✓f_✓i_✓l_✓e into the RCS file, deleting the existing text.
  187.           The _✓f_✓i_✓l_✓e name may not begin with -.
  188.  
  189.      -t-_✓s_✓t_✓r_✓i_✓n_✓g
  190.           Write descriptive text from the _✓s_✓t_✓r_✓i_✓n_✓g into the RCS
  191.           file, deleting the existing text.
  192.  
  193.  
  194.  
  195. Printed 1/29/91            1990/12/04                           3
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. CI(1)                  Programmer's Manual                  CI(1)
  203.  
  204.  
  205.  
  206.           The -t option, in both its forms, has effect only dur-
  207.           ing an initial checkin; it is silently ignored other-
  208.           wise.
  209.  
  210.           During the initial checkin, if -t is not given, ci
  211.           obtains the text from standard input, terminated by
  212.           end-of-file or by a line containing . by itself.  The
  213.           user is prompted for the text if interaction is possi-
  214.           ble; see -I.
  215.  
  216.           For backward compatibility with older versions of RCS,
  217.           a bare -t option is ignored.
  218.  
  219.      -w_✓l_✓o_✓g_✓i_✓n
  220.           uses _✓l_✓o_✓g_✓i_✓n for the author field of the deposited revi-
  221.           sion.  Useful for lying about the author, and for -k if
  222.           no author is available.
  223.  
  224.      -V_✓n  Emulate RCS version _✓n.  See co(1) for details.
  225.  
  226. FILE NAMING
  227.      Pairs of RCS files and working files may be specified in
  228.      three ways (see also the example section of co(1)).
  229.  
  230.      1) Both the RCS file and the working file are given.  The
  231.      RCS file name is of the form _✓p_✓a_✓t_✓h_✓1/_✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e,v and the work-
  232.      ing 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
  233.      _✓p_✓a_✓t_✓h_✓2/ are (possibly different or empty) paths and _✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e
  234.      is a file name.
  235.  
  236.      2) Only the RCS file is given.  Then the working file is
  237.      created in the current directory and its name is derived
  238.      from the name of the RCS file by removing _✓p_✓a_✓t_✓h_✓1/ and the
  239.      suffix ,v.
  240.  
  241.      3) Only the working file is given.  Then ci looks for an RCS
  242.      file of the form _✓p_✓a_✓t_✓h_✓2/RCS/_✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e,v or _✓p_✓a_✓t_✓h_✓2/_✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e,v
  243.      (in this order).
  244.  
  245.      If the RCS file is specified without a path in 1) and 2),
  246.      then ci looks for the RCS file first in the directory ./RCS
  247.      and then in the current directory.
  248.  
  249. FILE MODES
  250.      An RCS file created by ci inherits the read and execute per-
  251.      missions from the working file.  If the RCS file exists
  252.      already, ci preserves its read and execute permissions.  ci
  253.      always turns off all write permissions of RCS files.
  254.  
  255. FILES
  256.      Several temporary files may be created.  A semaphore file is
  257.      created in the directory containing the RCS file.  The
  258.  
  259.  
  260.  
  261. Printed 1/29/91            1990/12/04                           4
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. CI(1)                  Programmer's Manual                  CI(1)
  269.  
  270.  
  271.  
  272.      effective user+group must be able to read the RCS file and
  273.      to search and write the directory containing the RCS file.
  274.      Normally, the real user+group must be able to read the work-
  275.      ing file and to search and write the directory containing
  276.      the working file; however, some older hosts that do not con-
  277.      form to Posix 1003.1-1990 cannot easily switch between real
  278.      and effective ids, so on these hosts the effective
  279.      user+group is used for all accesses.  The effective
  280.      user+group is the same as the real user+group unless your
  281.      copy of RCS has setuid or setgid privileges.  These
  282.      privileges yield extra security if RCS files are protected
  283.      so that only the effective user+group can write RCS direc-
  284.      tories.  Further protection can be achieved by granting
  285.      access only to the effective user+group.
  286.  
  287.      ci never changes an RCS or working file; instead, it unlinks
  288.      the file and creates a new one.  This strategy breaks hard
  289.      links to such files, but does not affect symbolic links.
  290.  
  291. DIAGNOSTICS
  292.      For each revision, ci prints the RCS file, the working file,
  293.      and the number of both the deposited and the preceding revi-
  294.      sion.  The exit status is zero if and only if all operations
  295.      were successful.
  296.  
  297. IDENTIFICATION
  298.      Author: Walter F. Tichy.
  299.      Revision Number: 5.4; Release Date: 1990/12/04.
  300.      Copyright c 1982, 1988, 1989 by Walter F. Tichy.
  301.      Copyright c 1990 by Paul Eggert.
  302.  
  303. SEE ALSO
  304.      co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1),
  305.      rcsmerge(1), rlog(1), rcsfile(5)
  306.      Walter F. Tichy, RCS--A System for Version Control,
  307.      _✓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 15, 7 (July 1985), 637-654.
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327. Printed 1/29/91            1990/12/04                           5
  328.  
  329.  
  330.  
  331.