Jeff Hammel wrote:
I have written a plugin that essentially turns a post-commit-hook into a pluggable extension point:http://trac-hacks.org/wiki/SvnChangeListenerPlugin Essentially, I lifted code from http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook but broke the ticket changing logic and what should sit in svn's post-commit-hook into plugin, extension-point, respectively. In this way, ticket changing (which I put in http://trac-hacks.org/browser/svnchangelistenerplugin/0.11/svnchangelistener/ticketchanger.py) is isolated from the general logic of handling an svn commit. I think this adds value in allowing general plugins to respond to commits, allowing the use of python and standard trac configuration to perform its tasks. I would like to know if this is something generally useful to trac. SVN commits are also dealt with by the SVN policies plugin: http://trac-hacks.org/wiki/TracSvnPoliciesPlugin This plugin deals with direct editing of post + pre commit hooks and also does several other things, such as sending mail to users, enforcing commit messages, etc., that my plugin does not do (though they could be written as plugins with the ISVNChangeListener interface). My installer component (http://trac-hacks.org/browser/svnchangelistenerplugin/0.11/svnchangelistener/install.py) was written as an addendum and should probably be revisited. It is a different approach. I was curious if this componentization of the post-commit-hook (and potentially other hooks) is of interest to the community.
Haven't read the code, but +$BIGNUM on the idea at least. --Noah
signature.asc
Description: OpenPGP digital signature
