monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Building a notifier for use on a server. Feature re


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Building a notifier for use on a server. Feature request.
Date: Wed, 16 Feb 2005 22:13:26 -0800
User-agent: Mutt/1.5.6+20040907i

On Tue, Feb 15, 2005 at 02:56:42PM +0100, Christof Petig wrote:
> I also would like a feature like this. But my idea was to make the
> monotone server process emit a mail (or better: queue an event) once a
> new revision is synced into its database (LUA hook?). The revision ID
> would be enough to look up author, branch, diff, ancestors etc and mail
> them to a list. Graydon told me some time ago that such a mechanism
> already exists (though I had the impression that it could only track
> local checkins, no sync-ins).

Yes, I _think_ the way to do this is to add a 'note_netsync' hook,
similar to the current 'note_commit' hook, but a little more
complicated -- it needs to be notified of an arbitrary list of new
keys, new revisions, and new certs.  (It's important to do this all at
once, and include both revisions and certs, because such a hook would
want to be able to distinguish between the case where a new cert
arrives for a revision that we already have, and a new cert arrives
along with a new revision.)

Of course, as Richard points out, you still have to do some
post-processing to figure out what order to send out emails in and the
like, if you want to.  0.17 will have a nascent version of the
"automate" interface discussed on the list recently; this would be a
good project to work out what things should be added to that
interface... I'm thinking, maybe "parents_of", "children_of",
"ancestors_of", "descendents_of" would be useful commands?

There is some problem of, once your hook has been called, you probably
want to actually get at the corresponding data (like, say, to generate
unidiffs), and that can be sorta complicated -- your hook is being
called from inside the server, so it shouldn't block for any length
of time; and the server is continuing to use the database anyway.
Experimentation is probably needed here.

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey

This email may be read aloud.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]