bzr-hookless-email

[John Carr]

On Sat, Jan 24, 2009 at 3:38 PM, Martin Pool <mbp at sourcefrog.net> wrote:
> 2009/1/24 John Carr <john.carr at unrouted.co.uk>:
>> Any feedback on this? I'm faking Branch.hooks calls out of process (by
>> scanning the branch for changes since the last run) - is this a bad
>> thing? Should i provide my own hooks instead? If i do that, any ideas
>> on how plugins like bzr-cia can work with both sets of hooks without
>> lots of duplicated effort between each hook plugin?
>>
>> My branch at lp:~johncarr/+junk/bzr-watcher grew a bit more in the
>> meantime (added a watch command, added inotify back in).
>
> I haven't read (I can if you want) or tried the code yet but it sounds
> like a pretty good idea.
>
> Particularly if this can watch for inotify, it might be interesting to
> run even on a laptop to eg generate cia or direct-to-irc
> notifications, or to asynchronously push your work to a server to make
> sure it's backed up.

The branch has inotify, though i've not written tests for that yet. I
also wondered about using bzr-dbus as another optionals source of
triggers.

Interesting hook ideas.. If there are desktop and server use cases i
might want to add extension points to the plugin so that people (or
plugins) can alter the policy (e.g. have bzr-watcher start up and run
all the time, but inhibit scans while NetworkManager says no network.
When the network came online it would know what branches needed
scanning and get to work).

> I would say, ideally, one would be able to move a hook from being run
> synchronously on commit to being run asynchronously by bzr-watch by
> just changing one line in the configuration.

Are you happy for either one or the other? All synchronously or all
asynchronously. Or should it be configurable per plugin. Or per hook
name even.

> I would think that you should probably provide distinct hooks, and
> then have a way to redirect the registration of that plugin to go into
> your hook instead.  I think then you should generate your own relevant
> Result object and pass that to all your hooks.  But this is not a firm
> opinion; it depends on how it actually looks in the code.

This might have to go in bzr.dev, otherwise you can only write plugins
for the existing synchronous hook points that i cant override without
invading bzrlib..

> On a bit of a tangent, I'm interested in why you put this in +junk and
> not in a newly registered bzr-watch project.  I'm guessing that's
> because it's still experimental and you either weren't sure it
> deserved to be so visible as a project would make it and/or you
> thought making a project would take more effort than was worthwhile?
> Many branches seem to start out in +junk and I wonder if lp should
> change how it handles this.

I just didnt think it was worthy of a whole project, especially not just yet...

> --
> Martin <http://launchpad.net/~mbp/>
>

John