> Here's another question: is there any reason, other than the fact
> it would add additional complexity, that the act of composing and
> delivering the mail isn't done asynchronously? If you're doing a
> whopping big commit (vendor drop, say), the post-commit mailer run
> can take an inordinate length of time, especially if you're dealing
> with slow MTAs.
No. You can do it asynchronously: if you close all in- and outputs (on
unix) or if you start an independent process (on windows), the server
will stop waiting for input from the hook to send back to the client.
You can continue processing in 'headless' mode after that.
> i.e. have a little daemon that gets notified when <root>/db gets
> modified, at which point, it fires into action, checks the latest
> repo revision, checks the last revision it sent out a mail for,
> then sends out a mail for each revision in between. This could
> be expanded to handle transient delivery errors more gracefully,
> as opposed to the single-shot effect you get now with mailer.py.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-08 21:59:43 CEST