Jani Tiainen wrote:
Noah Kantrowitz kirjoitti: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'spost-commit-hook into plugin, extension-point, respectively. In this way,ticket changing (which I put inhttp://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 alsodoes several other things, such as sending mail to users, enforcing commitmessages, 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.This is how Redmine works. It doesn't have any hook but just piece of code that it calls when ever you access repository it updated tickets etc.
The plugin still require a push-driven hook script, just instead of calling a particular chunk of code for tickets you can call against an extension point.
--Noah
signature.asc
Description: OpenPGP digital signature
