home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 12 / CD_ASCQ_12_0294.iso / vrac / gr564b.zip / RCSINTRO.1 < prev    next >
Text File  |  1992-07-28  |  12KB  |  331 lines
  1.  
  2.  
  3.  
  4. RCSINTRO(1)                                           RCSINTRO(1)
  5.  
  6.  
  7. NNAAMMEE
  8.        rcsintro - introduction to RCS commands
  9.  
  10. DDEESSCCRRIIPPTTIIOONN
  11.        The Revision Control System (RCS) manages multiple
  12.        revisions of files.  RCS automates the storing, retrieval,
  13.        logging, identification, and merging of revisions.  RCS is
  14.        useful for text that is revised frequently, for example
  15.        programs, documentation, graphics, papers, and form
  16.        letters.
  17.  
  18.        The basic user interface is extremely simple.  The novice
  19.        only needs to learn two commands: ccii(1) and ccoo(1).  ccii,
  20.        short for ``check in'', deposits the contents of a file
  21.        into an archival file called an RCS file.  An RCS file
  22.        contains all revisions of a particular file.  ccoo, short
  23.        for ``check out'', retrieves revisions from an RCS file.
  24.  
  25.    FFuunnccttiioonnss ooff RRCCSS
  26.        +o      Store and retrieve multiple revisions of text.  RCS
  27.               saves all old revisions in a space efficient way.
  28.               Changes no longer destroy the original, because the
  29.               previous revisions remain accessible.  Revisions
  30.               can be retrieved according to ranges of revision
  31.               numbers, symbolic names, dates, authors, and
  32.               states.
  33.  
  34.        +o      Maintain a complete history of changes.  RCS logs
  35.               all changes automatically.  Besides the text of
  36.               each revision, RCS stores the author, the date and
  37.               time of check-in, and a log message summarizing the
  38.               change.  The logging makes it easy to find out what
  39.               happened to a module, without having to compare
  40.               source listings or having to track down colleagues.
  41.  
  42.        +o      Resolve access conflicts.  When two or more
  43.               programmers wish to modify the same revision, RCS
  44.               alerts the programmers and prevents one
  45.               modification from corrupting the other.
  46.  
  47.        +o      Maintain a tree of revisions.  RCS can maintain
  48.               separate lines of development for each module.  It
  49.               stores a tree structure that represents the
  50.               ancestral relationships among revisions.
  51.  
  52.        +o      Merge revisions and resolve conflicts.  Two
  53.               separate lines of development of a module can be
  54.               coalesced by merging.  If the revisions to be
  55.               merged affect the same sections of code, RCS alerts
  56.               the user about the overlapping changes.
  57.  
  58.        +o      Control releases and configurations.  Revisions can
  59.               be assigned symbolic names and marked as released,
  60.               stable, experimental, etc.  With these facilities,
  61.  
  62.  
  63.  
  64. GNU                         1992/02/17                          1
  65.  
  66.  
  67.  
  68.  
  69.  
  70. RCSINTRO(1)                                           RCSINTRO(1)
  71.  
  72.  
  73.               configurations of modules can be described simply
  74.               and directly.
  75.  
  76.        +o      Automatically identify each revision with name,
  77.               revision number, creation time, author, etc.  The
  78.               identification is like a stamp that can be embedded
  79.               at an appropriate place in the text of a revision.
  80.               The identification makes it simple to determine
  81.               which revisions of which modules make up a given
  82.               configuration.
  83.  
  84.        +o      Minimize secondary storage.  RCS needs little extra
  85.               space for the revisions (only the differences).  If
  86.               intermediate revisions are deleted, the
  87.               corresponding deltas are compressed accordingly.
  88.  
  89.    GGeettttiinngg SSttaarrtteedd wwiitthh RRCCSS
  90.        Suppose you have a file ff..cc that you wish to put under
  91.        control of RCS.  If you have not already done so, make an
  92.        RCS directory with the command
  93.  
  94.               mmkkddiirr  RRCCSS
  95.  
  96.        Then invoke the check-in command
  97.  
  98.               ccii  ff..cc
  99.  
  100.        This command creates an RCS file in the RRCCSS directory,
  101.        stores ff..cc into it as revision 1.1, and deletes ff..cc.  It
  102.        also asks you for a description.  The description should
  103.        be a synopsis of the contents of the file.  All later
  104.        check-in commands will ask you for a log entry, which
  105.        should summarize the changes that you made.
  106.  
  107.        Files in the RCS directory are called RCS files; the
  108.        others are called working files.  To get back the working
  109.        file ff..cc in the previous example, use the check-out
  110.        command
  111.  
  112.               ccoo  ff..cc
  113.  
  114.        This command extracts the latest revision from the RCS
  115.        file and writes it into ff..cc.  If you want to edit ff..cc, you
  116.        must lock it as you check it out with the command
  117.  
  118.               ccoo  --ll  ff..cc
  119.  
  120.        You can now edit ff..cc.
  121.  
  122.        Suppose after some editing you want to know what changes
  123.        that you have made.  The command
  124.  
  125.               rrccssddiiffff  ff..cc
  126.  
  127.  
  128.  
  129.  
  130. GNU                         1992/02/17                          2
  131.  
  132.  
  133.  
  134.  
  135.  
  136. RCSINTRO(1)                                           RCSINTRO(1)
  137.  
  138.  
  139.        tells you the difference between the most recently
  140.        checked-in version and the working file.  You can check
  141.        the file back in by invoking
  142.  
  143.               ccii  ff..cc
  144.  
  145.        This increments the revision number properly.
  146.  
  147.        If ccii complains with the message
  148.  
  149.               ccii eerrrroorr:: nnoo lloocckk sseett bbyy _y_o_u_r _n_a_m_e
  150.  
  151.        then you have tried to check in a file even though you did
  152.        not lock it when you checked it out.  Of course, it is too
  153.        late now to do the check-out with locking, because another
  154.        check-out would overwrite your modifications.  Instead,
  155.        invoke
  156.  
  157.               rrccss  --ll  ff..cc
  158.  
  159.        This command will lock the latest revision for you, unless
  160.        somebody else got ahead of you already.  In this case,
  161.        you'll have to negotiate with that person.
  162.  
  163.        Locking assures that you, and only you, can check in the
  164.        next update, and avoids nasty problems if several people
  165.        work on the same file.  Even if a revision is locked, it
  166.        can still be checked out for reading, compiling, etc.  All
  167.        that locking prevents is a _c_h_e_c_k_-_i_n by anybody but the
  168.        locker.
  169.  
  170.        If your RCS file is private, i.e., if you are the only
  171.        person who is going to deposit revisions into it, strict
  172.        locking is not needed and you can turn it off.  If strict
  173.        locking is turned off, the owner of the RCS file need not
  174.        have a lock for check-in; all others still do.  Turning
  175.        strict locking off and on is done with the commands
  176.  
  177.               rrccss  --UU  ff..cc     and     rrccss  --LL  ff..cc
  178.  
  179.        If you don't want to clutter your working directory with
  180.        RCS files, create a subdirectory called RRCCSS in your
  181.        working directory, and move all your RCS files there.  RCS
  182.        commands will look first into that directory to find
  183.        needed files.  All the commands discussed above will still
  184.        work, without any modification.  (Actually, pairs of RCS
  185.        and working files can be specified in three ways: (a) both
  186.        are given, (b) only the working file is given, (c) only
  187.        the RCS file is given.  Both RCS and working files may
  188.        have arbitrary path prefixes; RCS commands pair them up
  189.        intelligently.)
  190.  
  191.        To avoid the deletion of the working file during check-in
  192.        (in case you want to continue editing or compiling),
  193.  
  194.  
  195.  
  196. GNU                         1992/02/17                          3
  197.  
  198.  
  199.  
  200.  
  201.  
  202. RCSINTRO(1)                                           RCSINTRO(1)
  203.  
  204.  
  205.        invoke
  206.  
  207.               ccii  --ll  ff..cc     or     ccii  --uu  ff..cc
  208.  
  209.        These commands check in ff..cc as usual, but perform an
  210.        implicit check-out.  The first form also locks the checked
  211.        in revision, the second one doesn't.  Thus, these options
  212.        save you one check-out operation.  The first form is
  213.        useful if you want to continue editing, the second one if
  214.        you just want to read the file.  Both update the
  215.        identification markers in your working file (see below).
  216.  
  217.        You can give ccii the number you want assigned to a checked
  218.        in revision.  Assume all your revisions were numbered 1.1,
  219.        1.2, 1.3, etc., and you would like to start release 2.
  220.        The command
  221.  
  222.               ccii  --rr22  ff..cc     or     ccii  --rr22..11  ff..cc
  223.  
  224.        assigns the number 2.1 to the new revision.  From then on,
  225.        ccii will number the subsequent revisions with 2.2, 2.3,
  226.        etc.  The corresponding ccoo commands
  227.  
  228.               ccoo  --rr22  ff..cc     and     ccoo  --rr22..11  ff..cc
  229.  
  230.        retrieve the latest revision numbered 2._x and the revision
  231.        2.1, respectively.  ccoo without a revision number selects
  232.        the latest revision on the _t_r_u_n_k, i.e. the highest
  233.        revision with a number consisting of two fields.  Numbers
  234.        with more than two fields are needed for branches.  For
  235.        example, to start a branch at revision 1.3, invoke
  236.  
  237.               ccii  --rr11..33..11  ff..cc
  238.  
  239.        This command starts a branch numbered 1 at revision 1.3,
  240.        and assigns the number 1.3.1.1 to the new revision.  For
  241.        more information about branches, see rrccssffiillee(5).
  242.  
  243.    AAuuttoommaattiicc IIddeennttiiffiiccaattiioonn
  244.        RCS can put special strings for identification into your
  245.        source and object code.  To obtain such identification,
  246.        place the marker
  247.  
  248.               $$IIdd$$
  249.  
  250.        into your text, for instance inside a comment.  RCS will
  251.        replace this marker with a string of the form
  252.  
  253.               $$IIdd::  _f_i_l_e_n_a_m_e  _r_e_v_i_s_i_o_n  _d_a_t_e  _t_i_m_e  _a_u_t_h_o_r  _s_t_a_t_e
  254.               $$
  255.  
  256.        With such a marker on the first page of each module, you
  257.        can always see with which revision you are working.  RCS
  258.        keeps the markers up to date automatically.  To propagate
  259.  
  260.  
  261.  
  262. GNU                         1992/02/17                          4
  263.  
  264.  
  265.  
  266.  
  267.  
  268. RCSINTRO(1)                                           RCSINTRO(1)
  269.  
  270.  
  271.        the markers into your object code, simply put them into
  272.        literal character strings.  In C, this is done as follows:
  273.  
  274.               ssttaattiicc cchhaarr rrccssiidd[[]] == ""$$IIdd$$"";;
  275.  
  276.        The command iiddeenntt extracts such markers from any file,
  277.        even object code and dumps.  Thus, iiddeenntt lets you find out
  278.        which revisions of which modules were used in a given
  279.        program.
  280.  
  281.        You may also find it useful to put the marker $$LLoogg$$ into
  282.        your text, inside a comment.  This marker accumulates the
  283.        log messages that are requested during check-in.  Thus,
  284.        you can maintain the complete history of your file
  285.        directly inside it.  There are several additional
  286.        identification markers; see ccoo(1) for details.
  287.  
  288. IIDDEENNTTIIFFIICCAATTIIOONN
  289.        Author: Walter F. Tichy.
  290.        Revision Number: 5.2; Release Date: 1992/02/17.
  291.        Copyright 1982, 1988, 1989 by Walter F. Tichy.
  292.        Copyright 1990, 1991, 1992 by Paul Eggert.
  293.  
  294. SSEEEE AALLSSOO
  295.        ci(1), co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1),
  296.        rcsmerge(1), rlog(1)
  297.        Walter F. Tichy, RCS--A System for Version Control,
  298.        _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 1155, 7 (July 1985),
  299.        637-654.
  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.  
  328. GNU                         1992/02/17                          5
  329.  
  330.  
  331.