Max Bowsher wrote:
> John Peacock wrote:
>> Erik Huelsmann wrote:
>>> Or should we -instead- endorse mailer.py? I'm not at all that happy
>>> with maintaining duplicate functionality. Within the Subversion core
>>> we don't have much choice (as things stand), but do we need to do so
>>> when the alternative is obviously so much more advanced?
>> I agree - why does Subversion need to provide and maintain more than one
>> sample post-commit mailer? It's nice to have *something* included in
>> the core package, but when I tried to improve commit-email.pl.in, I
>> found to be not very easily rewritten (no jokes about all Perl code
>> being that way). ;-)
>>
>> We could also just mention SVN::Notify for the Perl-inclined, which is
>> at least as advanced and flexible as mailer.py (plus I have some
>> proprietary interest in that one, since I have several subclasses of it
>> that I have written/maintain).
>
> Well, I'm a Python person anyway, so I'm a bit biased, but...
>
> Yes, I would totally be happy with binning commit-email.pl and shipping
> a single endorsed solution for commit emails.
+1 on using mailer.py and deprecating commit-email.pl.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-12 03:02:08 CEST