[Trac] The future of RepositoryHookSystem plugin

25 views
Skip to first unread message

Olemis Lang

unread,
May 5, 2010, 5:17:04 PM5/5/10
to trac-users
Hello !

I've not been able to try and play with all features in 0.12 .
However, now that CommitTicketUpdater & Co. are (distributed with |
recommended for) 0.12 , and considering that :

- It's integrated with trac-admin , thus solving some of the
(IMHO) main issues with RepositoryHookSystem, i.e.
(the lack of a) global access point for invoking Trac
from inside commit hooks, windows support & ...
- Pluggable hooks architecture is already in core .
- The built-in solution is VCS agnostic
- ...

I was wondering what should be the future of RepositoryHookSystem
plugin . IOW which of the following decisions should (happen | be
made)

- Backport (core devs ;o) Trac 0.12 VCS hooks api to 0.11
- Abandon development of the plugin and mark it as deprecated
- Schedule further (few) remaining features implemented in the
plugin to merged with trunk
- Other ?

I'd really appreciate some feedback 'cause I'd not like spend my time
reinventing the wheel .

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
On adding AMF (RPC) support for Trac -
http://feedproxy.google.com/~r/simelo-en/~3/RDv-qDkEK_w/on-adding-amf-support-trac.html

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-...@googlegroups.com.
To unsubscribe from this group, send email to trac-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

Remy Blank

unread,
May 5, 2010, 5:22:32 PM5/5/10
to trac-...@googlegroups.com
Olemis Lang wrote:
> - Backport (core devs ;o) Trac 0.12 VCS hooks api to 0.11

This won't happen.

> - Abandon development of the plugin and mark it as deprecated

This will have to be answered by the plugin's author.

> - Schedule further (few) remaining features implemented in the
> plugin to merged with trunk

I haven't looked at the plugin for a while. What features would you like
to see ported from the plugin to core? If it's useful enough, we would
be glad to accept a patch.

-- Remy

signature.asc

Olemis Lang

unread,
May 5, 2010, 5:30:31 PM5/5/10
to trac-...@googlegroups.com
On Wed, May 5, 2010 at 4:22 PM, Remy Blank <remy....@pobox.com> wrote:
> Olemis Lang wrote:
>>   - Backport (core devs ;o) Trac 0.12 VCS hooks api to 0.11
>
> This won't happen.
>

:(

>>   - Abandon development of the plugin and mark it as deprecated
>
> This will have to be answered by the plugin's author.
>

I'm the current maintainer, that's why I'm concerned ;o)

>>   - Schedule further (few) remaining features implemented in the
>>      plugin to merged with trunk
>
> I haven't looked at the plugin for a while. What features would you like
> to see ported from the plugin to core? If it's useful enough, we would
> be glad to accept a patch.
>

The way I see it, the only thing that's missing are admin panels to
manage hooks for different VCS hooks (and even in that case further
work is needed for multi-repository support) . Beyond that, need to
check out

;o)

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Remy Blank

unread,
May 5, 2010, 7:00:23 PM5/5/10
to trac-...@googlegroups.com
Olemis Lang wrote:
> I'm the current maintainer, that's why I'm concerned ;o)

Oh, right, sorry :)

> The way I see it, the only thing that's missing are admin panels to
> manage hooks for different VCS hooks (and even in that case further
> work is needed for multi-repository support).

The file to be edited will differ from backend to backend. Even worse,
some backends (e.g. Mercurial) allow specifying hooks in several locations.

My feeling is that this is better left in a plugin, in the same way as
IniAdminPlugin and CustomFieldAdminPlugin. But that's only me.

-- Remy

signature.asc

Olemis Lang

unread,
May 5, 2010, 7:47:04 PM5/5/10
to trac-...@googlegroups.com

Olemis Lang

unread,
May 5, 2010, 8:24:26 PM5/5/10
to trac-...@googlegroups.com
On 5/5/10, Remy Blank <remy....@pobox.com> wrote:
> Olemis Lang wrote:
>> I'm the current maintainer, that's why I'm concerned ;o)
>
> Oh, right, sorry :)
>
>> The way I see it, the only thing that's missing are admin panels to
>> manage hooks for different VCS hooks (and even in that case further
>> work is needed for multi-repository support).
>
> The file to be edited will differ from backend to backend.

That's accurate. RepositoryHooksPlugin extensions are different from
the ones committed to trunk (and the architecture is slightly
different as well ;o). Below a comparison of interfaces (names might
not be accurate since I don't have source code at hand right now :-S )

|| RepositoryHookSystem || Trac 0.12b ||
|| IRepositoryHookSubscriber (VCS agnostic) || IRepositoryChangeListener ||
|| IRepositoryChangeListener (VCS specific) || ||
|| IRepositoryHookSetup || ||
|| IRepositoryHookAdminContributer || ||
|| IRepositoryHookSystem (mix-in ;o) || ||

RepositoryHookSystem might be a bit more powerful as well 'cause it
supports multiple hooks (currently SVN pre | post | * commit hooks )
and even builds «fake» changeset objects when needed (e.g. SVN
pre-commit hooks) . BTW:

- The version in trunk works just for post-commit
(or equivalent) hooks, or any hook and any VCS ?

> Even worse,
> some backends (e.g. Mercurial) allow specifying hooks in several locations.
>

Even worse ? Even better from (my | user) perspective ! More options
at hand . In fact you got me, I was about to start an implementation
for Hg soon ;o)

PS: I got your point ...

> My feeling is that this is better left in a plugin, in the same way as
> IniAdminPlugin and CustomFieldAdminPlugin. But that's only me.
>

Ok , so it's possible to start a 0.12 branch and implement this kind
of things in there (for 0.12). However it would be very nice if Trac
Team could backport repos hooks to 0.11 . Doing so the plugin could
focus on providing those aspects not covered by mainstream hooks
implementation . E.g. for some reason both approaches are different
(especially interfaces ;o) so it would be nice to make both solutions
more interoperable so that hook actions (components) may be written
once and used with both Trac 0.11 and 0.12 . Today that's not possible
'cause they are substantially different, different imports, ...

Since the backport might never happen , what could be done to route
both the plugin and Trac versions in the same direction ?

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Christian Boos

unread,
May 6, 2010, 3:57:59 AM5/6/10
to trac-...@googlegroups.com
On 5/6/2010 2:24 AM, Olemis Lang wrote:
> ...
> Ok , so it's possible to start a 0.12 branch and implement this kind
> of things in there (for 0.12). However it would be very nice if Trac
> Team could backport repos hooks to 0.11.

... which makes me think we probably have some communication issues
between the Trac dev team and the Trac plugin developers.

- 0.11.x is frozen, except if critical security issues are discovered
(last release will be 0.11.7.1 at the end of this month)

- 0.12 is being finalized, which means we might consider some small
last minute adjustments but other than that, it's "done"

- 0.13 development will begin soon, we're eager to get *more*
participation and feedback to the development discussions, and in
particular, any suggestions you could have concerning changes to
IRepositoryChangeListener can at best only target that release...

And it's not that we didn't try to get some involvement from the
community in the past 2 years, when we developed the multiple repository
support and even more specifically the IRepositoryChangeListener
interface. Search for IRepositoryChangeListener in the Trac-dev google
groups, you'll find lots of discussions.

So we're quite open to suggestions, but except when it's about fixing a
really serious flaw or some security issue, these things can only
concern *trunk* or feature branches (like sandbox/multirepos was), not
the stable branch, and even less the previous stable branch.

Now we can also try to make preview releases more often (earlier betas?
alphas even?), so that the new features and interfaces could catch the
attention earlier. What is sure is that long release cycles we had for
0.11 and 0.12 are not really optimal, and we'll try to shorten that for
the next releases (targeting 0.13 by end of this year), while trying to
keep the changes as incremental and as less disrupting as we can.

> Doing so the plugin could
> focus on providing those aspects not covered by mainstream hooks
> implementation . E.g. for some reason both approaches are different
> (especially interfaces ;o) so it would be nice to make both solutions
> more interoperable so that hook actions (components) may be written
> once and used with both Trac 0.11 and 0.12 . Today that's not possible
> 'cause they are substantially different, different imports, ...
>

I'd say write an adapter, i.e. one component forwarding the 0.12
IRepositoryChangeListener events to the components implementing your
interfaces?

-- Christian

Olemis Lang

unread,
May 6, 2010, 8:06:37 AM5/6/10
to trac-...@googlegroups.com
On Thu, May 6, 2010 at 2:57 AM, Christian Boos <cb...@neuf.fr> wrote:
> On 5/6/2010 2:24 AM, Olemis Lang wrote:
>>
>> ...
>> Ok , so it's possible to start a 0.12 branch and implement this kind
>> of things in there (for 0.12). However it would be very nice if Trac
>> Team could backport repos hooks to 0.11.
>
> ... which makes me think we probably have some communication issues between
> the Trac dev team and the Trac plugin developers.
>
>  - 0.11.x is frozen, except if critical security issues are discovered (last
> release will be 0.11.7.1 at the end of this month)
>
>  - 0.12 is being finalized, which means we might consider some small last
> minute adjustments but other than that, it's "done"
>
>  - 0.13 development will begin soon, we're eager to get *more* participation
> and feedback to the development discussions, and in particular, any
> suggestions you could have concerning changes to IRepositoryChangeListener
> can at best only target that release...
>
> And it's not that we didn't try to get some involvement from the community
> in the past 2 years, when we developed the multiple repository support and
> even more specifically the IRepositoryChangeListener interface. Search for
> IRepositoryChangeListener in the Trac-dev google groups, you'll find lots of
> discussions.
>

Well , I was not the maintainer of the plugin at that time , and
didn't even think of contributing to its development at that time :-/

> So we're quite open to suggestions, but except when it's about fixing a
> really serious flaw or some security issue, these things can only concern
> *trunk* or feature branches (like sandbox/multirepos was), not the stable
> branch, and even less the previous stable branch.
>

Ok, since you were backporting a few things in recent 0.11 branch, I
just thought that ...

>> Doing so the plugin could
>> focus on providing those aspects not covered by mainstream hooks
>> implementation . E.g. for some reason both approaches are different
>> (especially interfaces ;o) so it would be nice to make both solutions
>> more interoperable so that hook actions (components) may be written
>> once and used with both Trac 0.11 and 0.12 . Today that's not possible
>> 'cause they are substantially different, different imports, ...
>
> I'd say write an adapter, i.e. one component forwarding the 0.12
> IRepositoryChangeListener events to the components implementing your
> interfaces?
>

ok

PS: Trac 0.12 hooks are limited to post-commit(s) ?

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Remy Blank

unread,
May 6, 2010, 2:28:05 PM5/6/10
to trac-...@googlegroups.com
Olemis Lang wrote:
> PS: Trac 0.12 hooks are limited to post-commit(s) ?

The two hooks currently supported are post-commit (chaneset_added) and
post-revprop-change (changeset_modififed).

-- Remy

signature.asc

Olemis Lang

unread,
May 6, 2010, 3:13:19 PM5/6/10
to trac-...@googlegroups.com
I see . This means that some hooks mentioned recently in the list
(e.g. the pre-commit hook that aborts commits if no ticket ID is
provided in commit message) would not be supported yet via trac-admin,
isn' t it ?

JFTR, these kinds of hooks could be supported by RepositoryHookSystem
; but sometimes (e.g. SVN) a fake changeset object needs to be built
(and this means that the actual code to get this done varies from VCS
to VCS, thus justifying the structure of *different* interfaces in RHS
plugin ;o) . Moreover RHS allows to specify what actions will be
executed after triggering a particular hook.

Q:

- What about supporting this for 0.13 (at least the SVN impl
and the extension point for third party plugins ;o) ?
- What about adding a hook parameter to trac-admin
command ? I mean, with Mercurial and DVCS, similar
hooks might be invoked on different similar events (i.e.
not all for all events).
- If so , what'd be the (best | right) way to actually veto
the target changeset ?

OTOH

Q:
- What's the approach considered for Mercurial plugin ?
Is it gonna be distributed with Trac core (in the future) or
is it that it will always be a separate plugin ?

PS: All these are random thoughts for >=0.13 , of course ;o)
PS: PS: I'm just a bit talkative today :P
--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Remy Blank

unread,
May 6, 2010, 4:24:07 PM5/6/10
to trac-...@googlegroups.com
Olemis Lang wrote:
> - What about supporting this for 0.13 (at least the SVN impl
> and the extension point for third party plugins ;o) ?

As the name implies, an `IRepositoryChangeListener` listens for
repository *changes*. A pre-commit hook doesn't inform of a repository
change, so it's a bit outside of the intended scope.

> - What about adding a hook parameter to trac-admin
> command ? I mean, with Mercurial and DVCS, similar
> hooks might be invoked on different similar events (i.e.
> not all for all events).

I don't understand what you mean...

> - If so , what'd be the (best | right) way to actually veto
> the target changeset ?

Your example of vetoing a changeset that doesn't refer to a ticket
actually doesn't have anything to do with a Trac repository hook. What
you need is to extract any ticket references from the commit message,
something you can do with a regexp, and to check if that ticket exists.
For this, a `trac-admin $ENV ticket list` command would be useful
(possibly with an optional query), but you could also just use a SQL query.

> - What's the approach considered for Mercurial plugin ?
> Is it gonna be distributed with Trac core (in the future) or
> is it that it will always be a separate plugin ?

It will remain a separate plugin due to licensing issues (Mercurial is
GPL, Trac is BSD).

-- Remy

signature.asc

Olemis Lang

unread,
May 6, 2010, 4:41:13 PM5/6/10
to trac-...@googlegroups.com
On Thu, May 6, 2010 at 3:24 PM, Remy Blank <remy....@pobox.com> wrote:
> Olemis Lang wrote:
>>
[...]
>>   - What about adding a hook parameter to trac-admin
>>     command ? I mean, with Mercurial and DVCS, similar
>>     hooks might be invoked on different similar events (i.e.
>>     not all for all events).
>
> I don't understand what you mean...
>

E.g. Mercurial has

>>   - If so , what'd be the (best | right) way to actually veto
>>     the target changeset ?
>
> Your example of vetoing a changeset that doesn't refer to a ticket
> actually doesn't have anything to do with a Trac repository hook. What
> you need is to extract any ticket references from the commit message,
> something you can do with a regexp, and to check if that ticket exists.
> For this, a `trac-admin $ENV ticket list` command would be useful
> (possibly with an optional query), but you could also just use a SQL query.
>

Well , the idea was to implement this as a Trac plugin similar to
CommitTicketUpdater (more precisely RHS equivalent) but triggered on
pre-commit activation ;o) . However , the .

The (my) intention is to implement (all ?) kinds of hooks as Trac
plugins and manage them inside Trac GUI (e.g. using admin panels ;o)

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Hessian: Initial working implementation -
http://simelo.hg.sourceforge.net/hgweb/simelo/trac-rpcext/rev/ad5774008134

Olemis Lang

unread,
May 6, 2010, 4:50:29 PM5/6/10
to trac-...@googlegroups.com
On Thu, May 6, 2010 at 3:41 PM, Olemis Lang <ole...@gmail.com> wrote:
> On Thu, May 6, 2010 at 3:24 PM, Remy Blank <remy....@pobox.com> wrote:
>> Olemis Lang wrote:
>>>
> [...]
>>>   - What about adding a hook parameter to trac-admin
>>>     command ? I mean, with Mercurial and DVCS, similar
>>>     hooks might be invoked on different similar events (i.e.
>>>     not all for all events).
>>
>> I don't understand what you mean...
>
> E.g. Mercurial has
>

Sorry , Mercurial has commit, incoming, changegroup, ... I'm talking
about binding hooks like this

commit => Hook1, Hook2, Hook3
incoming => Hook2, Hook4, Hook5, Hook6
changegroup => Hook7, Hook8
...
Reply all
Reply to author
Forward
0 new messages