bzr-hookless-email

[John Carr]

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