home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 317a.lha / RCS / doc / ci.1l.doc < prev    next >
Text File  |  1989-12-05  |  11KB  |  331 lines
  1.  
  2.  
  3.  
  4. CI(1L)            UNKNOWN SECTION OF THE MANUAL            CI(1L)
  5.  
  6.  
  7.  
  8. NAME
  9.      ci - check in RCS revisions
  10.  
  11. SYNOPSIS
  12.      ci [ options ] file ...
  13.  
  14. DESCRIPTION
  15.      _C_i 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.   _C_i
  18.      deposits   the  contents  of  each  working  file  into  the
  19.      corresponding RCS file.  If only a working file is given, _c_i
  20.      tries  to  find  the corresponding RCS file in the directory
  21.      ./RCS and then in the current directory.  For more  details,
  22.      see the file naming section below.
  23.  
  24.      For _c_i 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, unless locking is set to _s_t_r_i_c_t  (see
  31.      _r_c_s(1L)).   A  lock  held by someone else may be broken with
  32.      the _r_c_s command.
  33.  
  34.      Normally, _c_i checks whether the revision to be deposited  is
  35.      different from the preceding one. If it is not different, _c_i
  36.      either aborts the deposit (if -q is given) or  asks  whether
  37.      to  abort  (if  -q is omitted). A deposit can be forced with
  38.      the -f option.
  39.  
  40.      For each revision deposited, _c_i prompts for a  log  message.
  41.      The log message should summarize the change and must be ter-
  42.      minated with a line containing a single `.' or a  control-D.
  43.      If  several  files  are checked in, _c_i asks whether to reuse
  44.      the previous log message.  If the standard input  is  not  a
  45.      terminal,  _c_i  suppresses  the  prompt and uses the same log
  46.      message for all files.  See also -m.
  47.  
  48.      The number of the deposited revision can be given by any  of
  49.      the options -r, -f, -k, -l, -u, or -q.
  50.  
  51.      If the RCS file does not exist, _c_i creates it  and  deposits
  52.      the  contents  of  the  working file as the initial revision
  53.      (default number: 1.1).  The access list  is  initialized  to
  54.      empty.   Instead of the log message, _c_i requests descriptive
  55.      text (see -t below).
  56.  
  57.      -r[_r_e_v]   assigns the revision number _r_e_v to the  checked-in
  58.                revision,  releases  the  corresponding  lock, and
  59.                deletes the working file.  This  is  the  default.
  60.  
  61.  
  62.  
  63. Purdue University         Last change:                          1
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. CI(1L)            UNKNOWN SECTION OF THE MANUAL            CI(1L)
  71.  
  72.  
  73.  
  74.                _R_e_v may be symbolic, numeric, or mixed.
  75.  
  76.                If _r_e_v is a revision number,  it  must  be  higher
  77.                than  the  latest  one  on the branch to which _r_e_v
  78.                belongs, or must start a new branch.
  79.  
  80.                If _r_e_v is a branch rather than a revision  number,
  81.                the  new  revision is appended to that branch. The
  82.                level number is obtained by incrementing  the  tip
  83.                revision  number of that branch.  If _r_e_v indicates
  84.                a non-existing branch, that branch is created with
  85.                the initial revision numbered _r_e_v.1.
  86.  
  87.                If _r_e_v is omitted, _c_i  tries  to  derive  the  new
  88.                revision  number  from  the caller's last lock. If
  89.                the caller  has  locked  the  tip  revision  of  a
  90.                branch,  the  new  revision  is  appended  to that
  91.                branch. The new revision  number  is  obtained  by
  92.                incrementing  the  tip  revision  number.   If the
  93.                caller locked a non-tip revision, a new branch  is
  94.                started  at  that  revision  by  incrementing  the
  95.                highest  branch  number  at  that  revision.   The
  96.                default initial branch and level numbers are 1.
  97.  
  98.                If _r_e_v is omitted and the caller has no lock,  but
  99.                he is the owner of the file and locking is not set
  100.                to _s_t_r_i_c_t, then the revision is  appended  to  the
  101.                default  branch  (normally  the  trunk; see the -b
  102.                option of _r_c_s(1L)).
  103.  
  104.                Exception: On the trunk, revisions can be appended
  105.                to the end, but not inserted.
  106.  
  107.      -f[_r_e_v]   forces a deposit; the new  revision  is  deposited
  108.                even it is not different from the preceding one.
  109.  
  110.      -k[_r_e_v]   searches the working file for  keyword  values  to
  111.                determine  its  revision  number,  creation  date,
  112.                state, and author (see _c_o(1)), and  assigns  these
  113.                values to the deposited revision, rather than com-
  114.                puting them locally.  It also generates a  default
  115.                login  message  noting the login of the caller and
  116.                the actual checkin date.  This  option  is  useful
  117.                for software distribution. A revision that is sent
  118.                to several sites should be checked in with the  -k
  119.                option  at  these  sites  to preserve the original
  120.                number, date, author, and  state.   The  extracted
  121.                keyword  values and the default log message may be
  122.                overridden with the options -r, -d,  -s,  -w,  and
  123.                -m.
  124.  
  125.      -l[_r_e_v]   works like -r, except it performs an additional _c_o
  126.  
  127.  
  128.  
  129. Purdue University         Last change:                          2
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. CI(1L)            UNKNOWN SECTION OF THE MANUAL            CI(1L)
  137.  
  138.  
  139.  
  140.                -l for the deposited revision. Thus, the deposited
  141.                revision is  immediately  checked  out  again  and
  142.                locked.   This  is  useful  for  saving a revision
  143.                although one wants to continue  editing  it  after
  144.                the checkin.
  145.  
  146.      -u[_r_e_v]   works like -l, except that the deposited  revision
  147.                is  not  locked.   This  is useful if one wants to
  148.                process (e.g., compile) the  revision  immediately
  149.                after checkin.
  150.  
  151.      -q[_r_e_v]   quiet mode; diagnostic output is not  printed.   A
  152.                revision  that is not different from the preceding
  153.                one is not deposited, unless -f is given.
  154.  
  155.      -d_d_a_t_e    uses _d_a_t_e for the checkin date and time.  _D_a_t_e may
  156.                be specified in free format as explained in _c_o(1).
  157.                Useful for lying about the checkin date,  and  for
  158.                -k if no date is available.
  159.  
  160.      -m_m_s_g     uses the string _m_s_g as the  log  message  for  all
  161.                revisions checked in.
  162.  
  163.      -n_n_a_m_e    assigns the symbolic name _n_a_m_e to  the  number  of
  164.                the  checked-in revision.  _C_i prints an error mes-
  165.                sage  if  _n_a_m_e  is  already  assigned  to  another
  166.                number.
  167.  
  168.      -N_n_a_m_e    same as -n, except that it  overrides  a  previous
  169.                assignment of _n_a_m_e.
  170.  
  171.      -s_s_t_a_t_e   sets the state of the checked-in revision  to  the
  172.                identifier _s_t_a_t_e.  The default is _E_x_p.
  173.  
  174.      -t[_t_x_t_f_i_l_e]
  175.                writes descriptive text into the RCS file (deletes
  176.                the  existing  text).   If  _t_x_t_f_i_l_e is omitted, _c_i
  177.                prompts the user for text supplied from the  stan-
  178.                dard  input,  terminated  with a line containing a
  179.                single `.' or control-D.  Otherwise, the  descrip-
  180.                tive text is copied from the file _t_x_t_f_i_l_e.  During
  181.                initialization, descriptive text is requested even
  182.                if  -t  is not given.  The prompt is suppressed if
  183.                standard input is not a terminal.
  184.  
  185.      -w_l_o_g_i_n   uses _l_o_g_i_n for the author field of  the  deposited
  186.                revision.   Useful for lying about the author, and
  187.                for -k if no author is available.
  188.  
  189. FILE NAMING
  190.      Pairs of RCS files and working files may be specified  in  3
  191.      ways (see also the example section of _c_o(1)).
  192.  
  193.  
  194.  
  195. Purdue University         Last change:                          3
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. CI(1L)            UNKNOWN SECTION OF THE MANUAL            CI(1L)
  203.  
  204.  
  205.  
  206.      1) Both the RCS file and the working file are given. The RCS
  207.      file  name  is  of the form _p_a_t_h_1/_w_o_r_k_f_i_l_e,_v and the working
  208.      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
  209.      _p_a_t_h_2/  are (possibly different or empty) paths and _w_o_r_k_f_i_l_e
  210.      is a file name.
  211.  
  212.      2) Only the RCS file is given.  Then  the  working  file  is
  213.      assumed  to  be  in  the  current  directory and its name is
  214.      derived from the name of the RCS file by removing _p_a_t_h_1/ and
  215.      the suffix ,_v.
  216.  
  217.      3) Only the working file is given. Then _c_i looks for an  RCS
  218.      file  of  the  form _p_a_t_h_2/_R_C_S/_w_o_r_k_f_i_l_e,_v or _p_a_t_h_2/_w_o_r_k_f_i_l_e,_v
  219.      (in this order).
  220.  
  221.      If the RCS file is specified without a path in  1)  and  2),
  222.      then  _c_i looks for the RCS file first in the directory ./RCS
  223.      and then in the current directory.
  224.  
  225. FILE MODES
  226.      An RCS file created by _c_i inherits the read and execute per-
  227.      missions  from  the  working  file.  If  the RCS file exists
  228.      already, _c_i preserves its read and execute permissions.   _C_i
  229.      always turns off all write permissions of RCS files.
  230.  
  231. FILES
  232.      The caller of the command must  have  read/write  permission
  233.      for  the directories containing the RCS file and the working
  234.      file, and read permission for the RCS file itself.  A number
  235.      of temporary files are created.  A semaphore file is created
  236.      in the directory containing the RCS file.  _C_i always creates
  237.      a new RCS file and unlinks the old one.  This strategy makes
  238.      links to RCS files useless.
  239.  
  240. DIAGNOSTICS
  241.      For each revision, _c_i prints the RCS file, the working file,
  242.      and the number of both the deposited and the preceding revi-
  243.      sion.  The exit  status  always  refers  to  the  last  file
  244.      checked in, and is 0 if the operation was successful, 1 oth-
  245.      erwise.
  246.  
  247. IDENTIFICATION
  248.      Author: Walter F. Tichy, Purdue University, West  Lafayette,
  249.      IN, 47907.
  250.      Revision Number: 1.3 ; Release Date: 89/05/02 .
  251.      Copyright c 1982, 1988, 1989 by Walter F. Tichy.
  252.  
  253. SEE ALSO
  254.      co(1L),  ident(1L),  rcs(1L),   rcsdiff(1L),   rcsintro(1L),
  255.      rcsmerge(1L), rlog(1L), rcsfile(5L)
  256.      Walter F. Tichy, "Design, Implementation, and Evaluation  of
  257.      a  Revision  Control  System,"  in  _P_r_o_c_e_e_d_i_n_g_s  _o_f  _t_h_e _6_t_h
  258.  
  259.  
  260.  
  261. Purdue University         Last change:                          4
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. CI(1L)            UNKNOWN SECTION OF THE MANUAL            CI(1L)
  269.  
  270.  
  271.  
  272.      _I_n_t_e_r_n_a_t_i_o_n_a_l  _C_o_n_f_e_r_e_n_c_e  _o_n  _S_o_f_t_w_a_r_e  _E_n_g_i_n_e_e_r_i_n_g,  IEEE,
  273.      Tokyo, Sept. 1982.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327. Purdue University         Last change:                          5
  328.  
  329.  
  330.  
  331.