home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / programm / 5336 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.9 KB  |  63 lines
  1. Newsgroups: comp.unix.programmer
  2. Path: sparky!uunet!caen!spool.mu.edu!mixcom.com!amby
  3. From: amby <amby@mixcom.mixcom.com>
  4. Subject: Re: RCS logfile usage
  5. Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.
  6. Distribution: usa
  7. Date: Wed, 18 Nov 1992 15:41:08 GMT
  8. Message-ID: <1992Nov18.154108.15231@mixcom.com>
  9. References: <1992Nov17.150301.23707@geac.com>
  10. Sender: ttvvtt@mixcom.com (Donald Amby)
  11. Lines: 50
  12.  
  13. In <1992Nov17.150301.23707@geac.com> adb@geac.com (Anthony DeBoer) writes:
  14.  
  15. >I'm currently in the process of setting up RCS, and after having tried
  16. >out various options and various test cases, I'm wondering about the
  17. >usefulness of the comments log feature versus just keying in change notes
  18. >in the source directly while editing.
  19.  
  20.     WE use CVS (which is a layer above) RCS.  The comments log (what you
  21.     get after the $Log$ tag) is a handy summary of what change was made in
  22.     each revision.  This is just a summary that gives an overview (as we
  23.     use it) of the changes.  To get a more detailed view, we look at the
  24.     difference listing itself.
  25.  
  26. >Direct keying lets you note the changes as you make them, while they're
  27. >fresh in your mind, as opposed to having to remember a summary of what
  28. >you did, to type in at checkin time.  Using the log feature, on the other
  29. >hand, seems to gain only that the rlog command will list the log
  30. >comments.  A third choice might be keeping the current change notes in a
  31. >separate file and doing "ci foo.c < foo.notes", but that requires editing
  32. >multiple files.
  33.  
  34.     If developers want to, they are free to add notes to the actual
  35.     changes that they make.  However, it is really not a requirement.
  36.     The idea is to keep all changes and their descriptions a permanent
  37.     part of the source (in the RCS control file).
  38.  
  39. >Using either feature gives you the comment changes during an rcsdiff, so
  40. >there's no difference there, and you can always see who changed what and
  41. >when.  Using $Log$ in the source does NOT buy you any log integrity;
  42. >other than adding the most current comment at checkout time, it does not
  43. >verify that previous comments are already there or that they haven't been
  44. >altered or damaged during later editing at some point.
  45.  
  46.     The $Log$ (and $Header$) information become more important if you
  47.     distribute any source files without the RCS control files (or CVS
  48.     repository in our case).
  49.  
  50.     We make use of $Header$ and $Log$ in every source file, along with
  51.     a @(#) to describe the function of the file.  This is so that we can:
  52.  
  53.     1. Determine the purpose of all files (what *) in directory.
  54.     2. Determine what release of all files (ident *) are in a directory.
  55.  
  56.     The $Log$ information gives a clue as to who had their hands in the
  57.     file, without access to the RCS control files.
  58. -- 
  59. Donald E. Amby
  60.     don@amby.mixcom.com   (for short mail)        (414)797-6713 (voice)
  61.     amby@eisner.decus.org (for lengthy mail)      (414)797-6533 (FAX)
  62.     Harnischfeger Engineers, Inc., P.O.Box 1512, Milwaukee, WI 53201-1512
  63.