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.
> > 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.
>
> >2) commit_email.pl doesn't handle renames really nicely. Right
> > now they look like this:
> >
> > Copied: Digest-MD5-2.16 (from rev 127, trunk/orca/packages/Digest-MD5-2.13)
> >
> > Copied: Storable-1.0.13 (from rev 127, trunk/orca/packages/Storable-1.0.11)
> >
> > It would be great if adds and deletes could be matched up.
> > This would be a lot easier if the Copied message that
> > 'svnlook diff' prints would print the complete path to the new
> > name.
> >
> > Does anybody mind if the first path name was changed? It
> > would make matching up named much easier.
> >
>
> Wouldn't it be better to have a Moved: section before the log message,
> just like the Added, Removed and Modified sections? That would make
> things nice and consistent.
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.
Best,
Blair
--
Blair Zajac <blair@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 2 02:54:50 2002