Interesting. Are any of you using commit hooks for peer review? I.e. "don't allow a change to go to repository unless it has been approved by 5 people"?
It seems like to implement this, you would need to initially submit your "RFCs" (policy changes) to a different system (like Trac, I guess), and then have that system commit to svn as soon as it has been approved? If you use svn directly, either the repository would get "contaminated" by unapproved changes (posting to Trac in post-commit), or nobody would be able to commit (pre-commit doesn't work because the script would need to wait for 5 people before finishing the commit?). Perhaps using multiple repositories would help? It would be very interesting to hear if any of you have smart solutions to this peer review problem. Thanks. -- Regards, Eystein On 01/28/2011 06:08 PM, Brett Delle Grazie wrote: > On 28 January 2011 17:00, Jesse Becker<becker...@mail.nih.gov> wrote: >> On Fri, Jan 28, 2011 at 10:27:18AM -0500, Mike Svoboda wrote: >>> >>> I?m using a SVN hook on post-commit to send a email to a bunch of >>> important folks with the SVN diff / files changed when I make a merge into >>> my production Cfengine branch. >>> >>> What cool tricks are other folks using on pre-commit / post-commit. >>> Anyone checking / creating JIRA tickets, validating the syntax of the >>> promises, or other cool stuff? I?d be curious to see what other folks are >>> doing. >> > > We have integrated our SVN repository with Trac (ticketing / project > management > system). The SVN hook simply blocks commits that don't reference an open > ticket in Trac. > > The hook is just the hook provided with Trac (in contrib). > >> We have a few pre/post commit hooks, and make use of svnlog. Nothing >> really fancy, but it could be expanded upon without too much trouble. >> I'd like to add basic syntax checking at some point. >> >> I've attached a cleaned copy of our post-commit script (the pre-commit >> amounts to "root can't commit to SVN"). >> >> The post-commit script calls the 'svnlog' program that is available >> from the subversion project to generate and send emails. We use v1.14, >> although that shouldn't matter much. (For those that don't know, it >> basically makes a pretty email that includes a 'diff' for the commit >> in question.) >> >> I'm sure there's room for improvement, but it works for us at the >> moment. >> >> -- >> Jesse Becker >> NHGRI Linux support (Digicon Contractor) >> >> _______________________________________________ >> Help-cfengine mailing list >> Help-cfengine@cfengine.org >> https://cfengine.org/mailman/listinfo/help-cfengine >> >> > > > _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine