Blair Zajac wrote:
>Branko ?ibej wrote:
>
>
>>Blair Zajac wrote:
>>
>>
>>
>>>Several things I want to do with commit_email.pl. Feedback needed.
>>>
>>>1) I have a svn tree with 6 different projects in it. I only
>>> want mods to specific portions of the tree emailed to specific
>>> mailing lists. So I'm thinking to add a table with two
>>> columns, the first is a regular expression to match against
>>> a path and the second is the email address. If any of the
>>> modified paths match the regular expression, then that email
>>> address gets sent the log.
>>>
>>>
>>>
>>That's a nice idea, but I don't think it makes sense to stop at the
>>emails. IMHO all the options should be per-project, if you go this way.
>>
>>
>
>Good point. Missed the other command line options.
>
>
>
>>> The question is, where to create the table. Should it be
>>> a list of command line arguments, something like
>>>
>>>
>>>
>>Just teach the script to read options from a file, and let the options
>>and mail addresses be intermingled, with each mail address using the
>>options that preceded it. Then you could have:
>>
>>commit-email.pl repos rev \
>> -m '^/proj1/' -r fred@here -l proj1.log proj1@here \
>> -m '^/proj2/' -l proj2.log proj2@here boss@here \
>> -m '^/' -l toplevel.log only.me@here
>> -@extra-config-file
>>
>>
>
>So the question here is if only.me@here gets a copy of all commits,
>or only commits that do not match any of the previous regexs.
>
>Right now, I would say yes, send email to any regex that matches.
>
>Also, if a commit matches both ^/proj1/ and ^/proj2/, then I will
>send the complete email to both mailing lists, the script will not
>split the commit into the portion that matches the regular expression.
>
Right.
BTW, I just remembered there has to be a way to reset an option's value
to the default. In the example above, you might not want "-r fred@here"
to hold fro all projects.
>>> Two other solutions are to hardwire the table in the script
>>> itself, but this is a pain when anybody updates the script
>>> (do you own diff and patch your own script) or to create a
>>> configuration file for the script and load in the list from
>>> there (cleaner, but yet another file to set up).
>>>
>>>
>>>
>>If you expect long command lines, you have to allow parameters to be
>>passed in files.
>>
>>
>
>I think I'll skip that for now, given that you can put the command
>line arguments nicely in a script.
>
I was thinking of command line length limits.
>Agreed. But to get the "Moved:" section, right now the script works
>with the output of 'svnlook diff', which prints
>
> Copied: Digest-MD5-2.16 (from rev 127, trunk/orca/packages/Digest-MD5-2.13)
>
>Changing the output to print trunk/orca/packages/Digest-MD5-2.16
>instead would make it easier and more reliable to match the output of
>that with 'svnlook changed' so the renamed files and directories can
>be removed from the Added, Removed and Modified sections.
>
>
What you'd want to do is modify "svndiff changed" to generate the
renames for you.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 2 03:06:48 2002