On Wed, Feb 16, 2005 at 10:27:09PM -0800, Robert Menschel wrote: >Hello George, > >Wednesday, February 16, 2005, 9:38:41 PM, you wrote: > >GG> Even if someone doesn't use RDJ, isn't a 2-10 line commented change log >GG> in the cf file worthwhile? > >GG> RDJ is not just for people who want to submit full trust. It can also >GG> be used to help automate distribution of fully validated enterprise >GG> rulesets, which happens to be the way I use it to distribute rulesets to >GG> my clients and is why I've been working with Chris Thielen to develop >GG> RDJ2, for better enterprise support and features that will help RDJ >GG> scale to support enterprise, and more clients and ruleset servers. > >GG> #@@# A note specifying the recent changes made, with a comment designed >GG> #@@# for grep-ing would be useful for the casual RDJ user to monitor >GG> #@@# what automatic updates are doing, as well as function to notify the >GG> #@@# enterprise admin of the changes he needs to validate, and integrate >GG> #@@# with his private rules. > >GG> If you are going through the trouble of publishing your rulesets for >GG> the ease of others to use, I don't see the point of forcing them to >GG> submit trust or manually discover changes when you publish them. > >Fair enough. In this most recent publication of updates to the >70_sare_header*.cf family, 40 rules were added, and 50 rules were >moved from one file to another, including 8 or 9 that were moved from >various files to the archive file. > >How would you structure a change history for those changes?
Are the files in cvs? I would suggest using the log keyword: http://cvsbook.red-bean.com/cvsbook.html#Using%20Keyword%20Expansion http://cvsbook.red-bean.com/cvsbook.html#Keyword%20Substitution%20(RCS%20Keywords) and record only the changes for a particular file with the commit for that file. Completely new files can be advertised on the website or an announce list. For example, with KeywordExpand=iLocker,Log in your CVSROOT/config file Your next commit will expand #@@# $Log$ To the entry you make when you commit, eg: #@@# $Log: README,v $ #@@# Revision 1.7 2005/02/17 15:42:54 geo #@@# #@@# Changed MSGID_WRONG due to high false negatives #@@# Added a log keyword. And noted changes made to this file. #@@# Added BROKE_SPAMWARE from Adam #@@# Added IDIOT_SPAMER from Jim Hoan #@@# Added FREE_MONEY from Joe John #@@# Added TEN_QUESTIONS from 70_sare_freefriends.cf #@@# Moved MAGIC_WORKS to 70_sare_oem.cf #@@# Removed TRIES_HARD due to false positives #@@# And that can be grep-ed and reported by various programs. The log will grow with each commit, but only the recent entry will be prepended. So any excessive/old lines can be removed right before your next commit. If you're not using cvs, it is defiantly worth taking up (nobody ever stops using it). Subversion (svn) may be a better choice, but I've not migrated to it yet. SVN is a re-implementation of cvs with CVS limitations addressed; not as widely used but I understand there is good discussion list support. // George (BTW cvsup is advertised as the most efficient way to distribute files, it is widely used to distribute incremental changes to OS source in the BSD world, and allows easy checkout of particular revisions or revision sets. That should be straight forward with a cvs ruleset repository in place. I'm not sure if SVN has a cvsup equivalent.) -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
