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. Jeff Hammel The Open Planning Project http://topp.openplans.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
