On 21/01/2009, at 15.03, Greg Stein wrote:
> On Wed, Jan 21, 2009 at 13:46, Jon Bendtsen <jbendtsen_at_laerdal.dk>
>>> So... I'm suggesting a more flexible way to parse the path and to
>>> assign names to each of the segments of the path.
>> Yes, but that is just purely cosmetic at and what you actually have
>> program your email client to sort and filter by. In our subversion to
>> and sort on branch, you would have to use the X-branch: header, and
>> your subversion would have to use the X-module: header. It is still
>> to do the filter and sort. But maybe confusing to some users.
> That was my thinking. When you give somebody instructions to filter
> out (say) the "contrib" portion of the Subversion repository by
> "Filter on X-branch like this ..."
> Their first question will be "branch? I want contrib changes from
> trunk." :-
But what if people wants more than module, branch, submodule and file.
What about directory and subdir, ...
Maybe we should add generic fields like
pf1, pf2, ... (Path Field 1, 2, ...)
>>> Because you defined the superclass to take that parameter. The
>>> MailedOutput.start() call is going to throw an exception because you
>>> don't pass the value.
>> I didnt experience exceptions or other faults on the ~25.000 changes
>> we had in our subversion repository. I started the script by "hand"
>> a dummy email address, and there was nothing on stdout or stderr.
> The exception would be raised if you use the smtp_hostname
> configuration option. I suspect you maybe used the mail_command
> configuration instead? Or maybe left both blank and generated to
> stdout instead?
i use mail_command. I can try using the smtp_hostname
>>>>> What is this stuff with [x] at the beginning? I see no doc about
>>>>> or other references/use.
>>>> what [x]? i do not understand. I stole the if_then_else from some
>>>> part of the script. I think it was where the group setup the from
>>> Oh. I see it now in other areas of the code. Something new that was
>>> added when I wasn't looking. Ugh.
>> I deliberately copied rather than code it myself.
> Yup. Not your fault at all!
> Now that I have found that stuff and figured out what it is for... it
> doesn't apply in this case. Being able to replace the "split
> character" is important for cases where whitespace can occur within
> the values. That will not be the case for your header logic. So we can
> keep it very simple with just a .split() and no testing for [.].
>>> No idea. But the point is that I don't think that comment should be
>>> there, since we don't actually add that field anywhere. (we *do* put
>>> "Author:" into the body of the message, however)
>> hmm, maybe it was a missing \n that cause it to show up in the
>> In the beginning my users requested an X-author: field, but when i
>> author: i figured i didnt have to add it.
> Ah! Quite possible.
> And yes, an X-author header should be quite easy to add. It would be
> handy if all commit email comes from the same From: address (such as
> codesite-noreply_at_google.com on Google Code).
Okay, i will consider adding it again.
Received on 2009-01-22 11:06:59 CET