[MERGE][RFC] Enhanced hooks

[Ian Clatworthy]

Robert Collins wrote:

> John suggested pattern matching shell scripts, a better approach is to
> user the idiom Debian and a growing number of upstream tools have for
> many configuration related things - FOO.d where all of the items in the
> directory foo.d are executed; and this is very friendly for shell users;
> its conceptually similar to the way bzr plugins are loaded (and why they
> are so easy to work with). We can definitely do this for shell scripts
> if we like (why should there be only one shell script post-commit
> called, for instance) - but I /really/ don't think shell script support
> belongs in core. It will just be too freaking hard to make it ROCK like
> in-process stuff does.

I've tried to capture some of this debate on
http://bazaar-vcs.org/BzrHooks under some new sections added at the end
today.

I can see that using directories has advantages. I can't say that I find
it clearly superior to using config files.

It's good to have this debate and I'm happy to let the patch float until
we get some consensus on the numerous issues:

* how should scripts be configured?
* should scripts be supported for all hooks or just some?
* what should the script signature look like for each?
* what is core and what is not?

I'd like to also state that the purpose of shell hooks IMO is *not* to
do magic things, so we shouldn't get bogged down on the basis that they
are inferior to our current approach (in terms of locking and
performance) for things like pre-commit. In my experience (and yours may
differ), people asking for shell hooks want to simply do the following
95% of the time:

* make target
* ant target
* send a message to another system

More often than not, Perl will be used for the last case as that's the
language the majority of sysadmins use for glue like this. Passing some
basic stuff in via string parameters is therefore good enough.

Beyond those boundaries, we should continue to champion our current
approach, not shell hooks.

Ian C.