On Mon, Sep 08, 2008 at 03:11:24PM -0400, C. Michael Pilato wrote:
> Erik Huelsmann wrote:
> > On Mon, Sep 8, 2008 at 8:36 PM, Trent Nelson
> >> You know what would be nice? If the out-of-the-box Subversion 1.5
> >> installer on Windows shipped not only mailer.py, but diff.exe and
> >> the .dlls as well. Oh, and used subprocess, if available.
> > How about -instead of using diff.exe- using the built-in diff engine
> > (libsvn_diff)? It's available to use from the python bindings and - if
> > you think that won't do it for you - you could instead use 'svnlook
> > diff' which extracts the diffs right out of the repository, whenever
> > possible.
> Or maybe even Python's own difflib implementation (if version 2.3 or
> greater)? :-)
You know, I remember trying vehemently to get difflib to play
nicely so I didn't have to depend on diff.exe. I can't remember
specifics, other than the fact I gave up after a while and just
used diff.exe -- I think it was because no matter how hard I tried,
difflib could not be coerced into behaving identically to diff.exe.
Will look into it again though.
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.
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.
(This is how I was planning on implementing the Python module
that sync's svn changeset information into a relational database,
which I don't want to put in a post-commit hook. It would be a
good fit for a mailer.py 2.0 as well, I think.)
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:44:01 CEST