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.
I know this is a little late in the reply but wanted to get this in before this becomes "official" (sorry fro the delay, it's due to my own laziness and Gmane+Google Groups setup at my end) I think other people have commented that this should not specifically mention SVN so that covered but one thing I did think about which IIRC is unique to SVN is revprops. When you update a commit message via a revprop, it would be nice to be able to ping trac to tell it to resync that commit. It should be possible to trigger this listener when that happens too but I think it's important to ensure it's a different method that is called so appropriate action can be taken (perhaps the old value of the property that has changed could be passed in somehow?). For most plugins/listeners the rev prop method would just call the main listener method, but havign them split out from the beginning would be IMO useful. Apologies if this has been covered already and I've just missed it :) Col --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
