home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / software / 2911 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.4 KB

  1. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!genome.lbl.gov!bsherman
  2. From: bsherman@genome.lbl.gov (Brad Sherman)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: SCCS - RCS driver scripts (snapshot)
  5. Date: 21 Jul 1992 20:45:19 GMT
  6. Organization: Institute of Forest Genetics DataBase
  7. Lines: 38
  8. Message-ID: <24768@dog.ee.lbl.gov>
  9. References: <75cmh9k.qualtrak@netcom.com>
  10. Reply-To: bsherman@genome.lbl.gov (Brad Sherman)
  11. NNTP-Posting-Host: 131.243.224.80
  12. Keywords: SCCS RCS
  13.  
  14. In article <75cmh9k.qualtrak@netcom.com> jb@QualTrak.COM writes:
  15. >
  16. >My boss is interested in shell scripts which may be used in conjunction
  17. >with SCCS or RCS to handle snapshots of sets of files in a directory
  18. >hierarchy (or possibly multiple directory hierarchies) based either on
  19. >date-time or the revision id.
  20. > ...
  21.  
  22. [This is an answer to your question only in so far as you are 
  23. attempting to do "release engineering." -bks]
  24.  
  25. Let me save your boss a ton of money and protect you from an ulcer
  26. at the same time.  There is no such thing as a snapshot using SCCS
  27. and/or RCS.  All you will get (if you're exceedingly meticulous)
  28. is an accurate reproduction of the source code, local headers
  29. and makefiles.  However the compiler and libraries may be completely
  30. different.  System headers may have gone through fifteen changes
  31. (probably in an attempt to become ANSI compliant, or System V r X.X
  32. compliant, or X17 compliant or some such).
  33.  
  34. What you should do is buy a machine for each and every release of
  35. your software.  That machine is then the "snapshot" of the release.
  36. Do _not_ upgrade any software on that machine.  Then if the
  37. engineer wants to track down a problem with release 4.1.6.3 of
  38. your software all she has to do is sit down at machine 4.1.6.3
  39. and start working.  SCCS is then handy for keeping track of the
  40. quick and dirty patches used between releases to keep the customer
  41. happy.  It may be necessary to update other release-machines to
  42. reflect the fix, but this is not automatically the case.
  43.  
  44. I know that this sounds expensive, but in the long run it will 
  45. keep the workers happy, the customers happy and the bottom line
  46. happy.   SCCS is very nice for between release development, and
  47. great for keeping track of changes to system configuration files
  48. but do _not_ expect it to be an easy route to restoring the state 
  49. of a machine at the time that a release was prepared.
  50. --------------------
  51.     --Brad Sherman
  52.