bzr-hookless-email

[John Carr]

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).

John

On Fri, Jan 16, 2009 at 3:29 PM, John Carr <john.carr at unrouted.co.uk> wrote:
> On Tue, Jan 13, 2009 at 1:57 PM, Wouter van Heyst
> <larstiq at larstiq.dyndns.org> wrote:
>> Hi all,
>>
>> at work we run bzr-hookless-email on the central server, when changes
>> are available centrally the daemon notices this using inotify and sends
>> out new mail.
>>
>> A drawback of running in daemon mode used to be that it didn't notice
>> newly created branches, but yesterday I added some code to pick up on
>> those and start watching them. (available from lp:bzr-hookless-email)
>>
>> One issue I haven't decided on yet is what to mail for new branches,
>> just a mail "new branch available" with the log for -r -1, or the entire
>> log of the branch, or maybe look around in the repository for siblings
>> and mail about the "truely" new revisions?
>>
>> Thoughts on this are welcome, as are suggestions for how to differently
>> solve the "mail-on-centrally-available" problem.
>>
>> Wouter van Heyst
>
> Hi
>
> So I have been looking at bzr-hookless-email and wondering if it was
> the right fit for my needs. I actually have a couple of tasks that
> need to happen after a branch is pushed to the central server, some
> per branch tip update and some per commit - and not all of them are
> emails. What i really want is to use plugins and hooks to add new
> tasks to bzr-hookless-email. At which point, the name kind of doesnt
> fit any more...
>
> So here is my test branch:
>
> lp:~johncarr/~junk/bzr-watcher
>
> It's geared up as though its a bzr plugin, but theres no new exposed
> dials or buttons yet. It just has a class that generates events for
> commits since the last scan and a *single* post change branch tip fire
> that encompasses any and all changes. So yes, multiple
> post_change_branch_tip events do get squished into a single event
> here... There are a couple of tests for what hooks it fires in a few
> different scenarios. There is deliberately no way to make it actually
> do anything (outside of the test suites). This will probably have
> changed by my bed time...
>
> The big question is, what hooks should it fire. At the moment, i'm
> faking actual Branch.hooks post-commit / post-change-branch-tip
> activity. So if i push to a server with this code running, the push
> and a later scan could possibly maybe both fire hooks for the same
> event, so it should have its own hook points. But theres no reason (i
> think) why bzr-cia couldnt "just work" here, so i want to do something
> where it can work for both in-process push-time events and out of
> process after-the-fact events. And in the first case, a dependency on
> a plugin would seem silly.
>
> The scanner could have its own plugins directory, but im not sure that
> is very nice..
>
> Oh, in theory I think this would work against svn repositories and git
> repositiories too (if you have bzr-svn or bzr-git)..
>
> Thoughts? Ideas? Innnpuuttt?
>
> John
>