SVN Change Listener Plugin

[Jeff Hammel]

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

[Noah Kantrowitz]

Haven't read the code, but +$BIGNUM on the idea at least.

--Noah

[Jani Tiainen]

Noah Kantrowitz kirjoitti:

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.

Draw back is that you lose realtime notifications. If you close ticket
you get that email (and actual close) next time you hit repository. Good
thing is that this works with even remote repositories pretty well.

--

Jani Tiainen

[Noah Kantrowitz]

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

[Emmanuel Blot]

> Haven't read the code, but +$BIGNUM on the idea at least.

+1 as well, I think Trac core needs such an Interface, although I
believe it should not be tied to a specific SCM: an
"IVersionControlChangeListener" or "IRepositoryChangeListener" to
follow the current naming scheme.

--
Manu

[Erik Bray]

On Fri, Jun 20, 2008 at 12:01 AM, Jeff Hammel <jha...@openplans.org> wrote:
>
> I have written a plugin that essentially turns a post-commit-hook into a
> pluggable extension point:
>
> http://trac-hacks.org/wiki/SvnChangeListenerPlugin
>

Very nice--I've had to write a few post-commit hooks for Trac in the
past. For example, for a usage auditing script in which I could
easily make use of the IWikiChangeListener and such interfaces, but
lacked an "IRepositoryChangeListener". Even if it does have to be
backed by a hook script (which it certainly does) I love the idea of
providing a generic interface for this instead of having to write
additional hook scripts for everything.

Erik

[Jeff Hammel]

Agreed that this should be generalized to work with any SCM type that trac supports. I haven't played with any of the other SCMs and trac together, so I'm not sure if (for instance) changeset objects all conform to the same interface. But were this the case, and the actual on_change function can be assumed to work the same for all repos, then it'd be my inclination that this be generalized, the SVN post-commit-hook case just being an example of the actual pusher of changes.

jeff

[Colin Guthrie]

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

[Jeff Hammel]

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.

[Colin Guthrie]

Jeff Hammel wrote:
> 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.

Cool, has this been committed yet anyway or is there a tracking ticket
for it?

I'd be keen to get this in before it's widely adopted (changing
interfaces sucks!), assuming of course that it's not totally insane.

The main reason I use rev-props is when a ticket is incorrectly
referenced in a commit. Here any listener may want to take corrective
action when something is changed. At least that's my thinking!

Col

[Jeff Hammel]

Its a legitimate use-case, just not something we do here. (We nevre make
mistakes ;) The plugin itself is here:

http://trac-hacks.org/wiki/SvnChangeListenerPlugin

There should be a link to creating a new ticket if you'd like.

jeff

[Colin Guthrie]

Jeff Hammel wrote:
> Its a legitimate use-case, just not something we do here. (We nevre make
> mistakes ;) The plugin itself is here:

I wonder if you deliberately spelt never wrong.... either way, funny or
delicious irony :D

> http://trac-hacks.org/wiki/SvnChangeListenerPlugin

Gah, I see that in the original mail now. Silly me. I did my reply a
long time after reading the original and totally forgot that this detail
was in it and that it was on Trac Hacks :D

Will bash out a patch at some point.

Col

[Jeff Hammel]

On Mon, Jul 07, 2008 at 09:35:41AM +0100, Colin Guthrie wrote:
>
> Jeff Hammel wrote:
> > Its a legitimate use-case, just not something we do here. (We nevre make
> > mistakes ;) The plugin itself is here:
>
> I wonder if you deliberately spelt never wrong.... either way, funny or
> delicious irony :D

In the spirit of fun, i'll let you interpret however you want.

> > http://trac-hacks.org/wiki/SvnChangeListenerPlugin
>
> Gah, I see that in the original mail now. Silly me. I did my reply a
> long time after reading the original and totally forgot that this detail
> was in it and that it was on Trac Hacks :D
>
> Will bash out a patch at some point.

See also existing ticket: http://trac-hacks.org/ticket/3312

I should also noted that I banged out SvnChangeListener quickly as a proof of concept and meant to return to it, add more hooks, and make it nicer. I haven't done any of that yet, so my apologies.