Context Navigation

turn repository hooks into pluggable extension points

This plugin has only been tested with SVN's post-commit hook. Additional work may be required to get this to work with other SCMs or other SVN hooks. Please contact the author or open a ticket if you need additional functionality for this plugin (contributors also welcome). If you're looking for plugins that work with SVN hooks, you might also try the SvnChangeListenerPlugin or the TracSvnPoliciesPlugin, or perhaps the contributed ​trac post-commit hook is sufficient for your purposes.

Description

The RepositoryHookSystemPlugin is designed to turn repository hooks, such as SVN's post-commit hook, into extension points so that arbitrary trac plugins may be built that have full access to the trac framework to act on repository commits.

the RepositoryHookSystemPlugin provides an extension point (!IRepositoryHookSubscriber) which may be populated with configurable hooks that have access to their trac environment

the RepositoryHookSystemPlugin is able to enable and disable its presence in the SVN hooks directory without affecting other plugins

has a webadmin interface for configuring hooks including figuring out whether or not the plugin has been enabled on a per-project basis

plugins can be enabled on a per-hook basis

the listeners are invoked via a command-line call from one of the repository hooks. This is a one-line command that passes whatever details are necessary to identify the changeset.

a trac changeset object is used to pass around information. This is good, as it avoids unneccessary information to be sought by the RepositoryChangeListeners. For the SvnChangeListenerPlugin (at least as it stands living only in the post-commit hook), this is sufficient. It is unknown whether this is a good idea for other hooks and repository systems. If a unified interface for a changeset object were available, then a changeset object could be &#34;fakeable&#34; if its not available (like it is at SVN post-commit). If not, this is a big conceptual hole. To be investigated.

the logic of the RepositoryChangeListeners is agnostic to SCM type and hook used.

arbitrary version control systems, with an &adapter; for the version control system used to an implementation capable of hook invocation

arbitrary hooks, not just post-commit

[BETA] However, while architected, this plugin has only been tested with SVN and will probably only work with the SVN post-commit hook for now [BETA]. The reason for this is that the RepositoryHookSystemPlugin uses changeset-like objects as a means of passing data. This works for SVN's post-commit-hook, but for other hooks it may be necessary to build or mock a changeset object. I haven't done any work in this direction, though if there is community interest than I would pursue it.