home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / question / 14613 < prev    next >
Encoding:
Text File  |  1992-12-11  |  3.5 KB  |  91 lines
  1. Newsgroups: comp.unix.questions,cs.questions
  2. Path: sparky!uunet!psinntp!dg-rtp!webo!dg-webo!pds
  3. From: pds@lemming.webo.dg.com (Paul D. Smith)
  4. Subject: Re: RCS usage
  5. Sender: usenet@webo.dg.com (Usenet Administration)
  6. Message-ID: <PDS.92Dec10173836@lemming.webo.dg.com>
  7. In-Reply-To: tk@dcs.ed.ac.uk's message of 9 Dec 92 22:37:03 GMT
  8. Date: 10 Dec 92 22:38:36 GMT
  9. To: tk@dcs.ed.ac.uk (Tommy Kelly), ajw.dcs.ed.ac.uk (Amanda Welsh)
  10. Lines: 76
  11. References: <Bz0K5r.5K5@dcs.ed.ac.uk>
  12. Organization: NSDD/ONSD, Data General Corp., Westboro, MA
  13. Lines: 76
  14.  
  15. [] Regarding RCS usage;
  16. [] tk@dcs.ed.ac.uk (Tommy Kelly) writes:
  17.  
  18.     tk> Suppose I have five source files, A, B, C, D and E which make
  19.     tk> up an application.  As I develop the application, I want to
  20.     tk> keep track of which revisions of each file combine to create a
  21.     tk> particular version of my application.
  22.  
  23.     tk> At the moment I am keeping a shellscript also under RCS which
  24.     tk> checks out all required revisions (along with relevant README,
  25.     tk> Makefile, etc).  I update that shellscript each time I am
  26.     tk> satisfied with a new version.  Every time I want a particular
  27.     tk> version of my application, I check out that revision of my
  28.     tk> shellscript and run it.
  29.  
  30.     tk> Question: Is there an easier way to do this, perhaps using RCS
  31.     tk> itself?
  32.  
  33. These are the kinds of things one uses source control *for*, so you
  34. don't need to do all that mess.
  35.  
  36. There are at *least* two easy ways to do this.
  37.  
  38. (a) The most obvious and natural is to update the RCS major revision
  39.     each time you create a version you want to keep track of.
  40.  
  41.     So after you get to a certain point you decide you're done with
  42.     this "version", which has RCS major rev 1 (files have versions
  43.     like 1.1, 1.2, 1.3, etc.), co -l all your files, then
  44.     use something like:
  45.  
  46.         ci -f -m"Updating to new vesion 2.0" -r2 <files>
  47.  
  48.     This will check in all your files with a new major rev number,
  49.     starting with 2.1, then 2.2, etc.
  50.  
  51.     If you want the "version 1" files back, just say:
  52.  
  53.         co -r1 <files>
  54.  
  55.     Note that if you don't give a minor version number, RCS
  56.     automatically substitutes the latest rev.  So that checks out the
  57.     last version of each file in <files> with major revision 1.
  58.  
  59.     This is definitely the best way to keep track of "major stopping
  60.     points", like versions released to others.
  61.  
  62. (b) Better for "your own information" version numbers, where you just
  63.     might want to get back these files but it's not a "real" stopping
  64.     point, is to name each revision: just say:
  65.  
  66.         rcs -nMY_REV:1 <files>
  67.  
  68.     This will associate the symbolic name MY_REV with the latest
  69.     version of major revision 1 in each file in <files>.
  70.  
  71.     MY_REV can be used in place of any revision on any RCS command, so
  72.     you could then say:
  73.  
  74.         co -rMY_REV <files>
  75.  
  76.     To get all the files so marked.
  77.  
  78. You should really spend some time reading the ci(1), co(1), and rcs(1)
  79. man pages and familiarize yourself with the features of RCS.  They are
  80. many and powerful :)
  81. --
  82.  
  83.                                                                 paul
  84. -----
  85.  ------------------------------------------------------------------
  86. | Paul D. Smith                          |    paul_smith@dg.com    |
  87. | Data General Corp.                     | pds@lemming.webo.dg.com |
  88. | Network Systems Development Division   |                         |
  89. | Open Network Systems Development       |   "Pretty Damn S..."    |
  90.  ------------------------------------------------------------------
  91.