[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] mailer.py

From: Mathias Weinert <mathias.weinert_at_gfa-net.de>
Date: 2006-03-01 09:46:35 CET

Referring to http://svn.haxx.se/dev/archive-2006-02/0293.shtml Max Bowsher wrote:

> I feel that the design proposed is somewhat inelegant, but I don't have
> any clear ideas on how to make it better. I left the message alone
> hoping other people might have less clouded opinions.

For me it would be very helpful to have a different character
but the default whitespaces to separate different mail addresses
(as described in the original post).

I see four possibilities to achieve this:
1. Change the default behavior from whitespace to comma
   -> May result in problems for people updating to this version
2. Introduce a new parameter to specify the separator
   -> As I did in my patch
3. Introduce a new parameter for to_addr which will be splitted
   by comma and deprecate the current one
   -> That's what Greg Stein proposed
3. Introduce a new parameter for to_addr which will be splitted
   by comma and then add these mail addresses to the ones given
   by the current to_addr parameter
   -> No deprecation, no update problems, but two parameters for
      the same thing

I don't matter which of them will be used but I would be happy
if any at all will be used.

Do you have any objections against the second change in the
patch
(* tools/hook-scripts/mailer/mailer.py
  - it's now possible to use capital letters in option values
    which will be passed through a map
* tools/hook-scripts/mailer/mailer.conf.example
  - added a hint to the description of the mapping process)?

Mathias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 1 09:47:39 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.