home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 4919 < prev    next >
Encoding:
Text File  |  1992-12-13  |  2.5 KB  |  64 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!enterpoop.mit.edu!spool.mu.edu!mixcom.com!amby
  3. From: amby <amby@mixcom.mixcom.com>
  4. Subject: Re: C Code Layout
  5. Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.
  6. Distribution: usa
  7. Date: Sun, 13 Dec 1992 15:18:01 GMT
  8. Message-ID: <1992Dec13.151801.6059@mixcom.com>
  9. References: <2933199653.8.wk01673@worldlink.com>
  10. Sender: ttvvtt@mixcom.com (Donald Amby)
  11. Lines: 51
  12.  
  13. In <2933199653.8.wk01673@worldlink.com> "Lih Yen Hsieh" <wk01673@worldlink.com> writes:
  14.  
  15. >Tom Johnson <tomj@monster.apd.saic.com> writes:
  16. >>mueller@b30news.b30.ingr.com ( Phil Mueller ) writes:
  17. >>>       Author     Date          Description
  18. >>>       -----      ----          -----------
  19.  
  20.     I prefer to have version control tools generate this.  Then it should
  21.     be consistent with what I get from querying the version control
  22.     system (we use CVS, which is on top of RCS).
  23.  
  24. >Inclusion of historical information about the module certainly helps track
  25. >the evolution of the piece of code of interest.  Points of relevance:
  26.  
  27.     Only, when the username being used by developers is unique for each
  28.     user.  While we use a version control system, seme developers have
  29.     a history of making changes via "shared" usernames.  I never do that,
  30.     but not everyone takes my advice.
  31.  
  32. >Practically, if you are in a production environment, this is not only
  33. >a good thing to have, but also indispensible and should be enforced.
  34.  
  35.     By doing that, in conjunction with tools like CVS, RCS, or even SCCS
  36.     it is a simple matter to document who is doing what on the sources.
  37.     Also, I find it trivial to answer questions like:
  38.  
  39.     * What changes have I made since 1 Nov 1992?
  40.  
  41.         cvs history -c -D11/1/1992
  42.  
  43.     * What files have changed since last release (V1_0) on system xxx?
  44.  
  45.         cvs rdiff -s -rV1_0 xxx
  46.  
  47.     Of course, these examples are specific to using CVS, but you get 
  48.     the idea.  I have scripts that do this type of querying, in order to
  49.     write up my project status reports.
  50.  
  51. >If you are familiar with Unix tools, such as sed, awk, and the like, you
  52. >can craft non-trivial tools together with revision control and the make
  53. >program to somewhat mechanize this 'chore'.
  54.  
  55.     Or you can just buy a system, and let the vendor deal with it.
  56.     Or you can use tools that lay on top of SCCS or RCS (which CVS does)
  57.     to make it easy to manage whole directory trees as easily as one file.
  58.  
  59. -- 
  60. Donald E. Amby
  61.     don@amby.mixcom.com   (for short mail)        (414)797-6713 (voice)
  62.     amby@eisner.decus.org (for lengthy mail)      (414)797-6533 (FAX)
  63.     Harnischfeger Engineers, Inc., P.O.Box 1512, Milwaukee, WI 53201-1512
  64.