On Wed, Jul 02, 2008 at 01:12:37PM +0100, Colin Guthrie wrote: > > 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're welcome to ticket and/or implement. At my office, we never change revprops after the commit so its not a priority for me. 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 -~----------~----~----~----~------~----~------~--~---
