You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2002/07/02 00:09:07 UTC
commit_email.pl improvements
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.
The question is, where to create the table. Should it be
a list of command line arguments, something like
% commit_email.pl ${REPOS} ${REV} \
-match '^/(trunk|tag|branches)/proj1/' proj1@xyz.com \
-match '^/(trunk|tag|branches)/proj2/' proj2@abc.com
catchall@abc.com
Here -match takes two values off the command line, the regex
and an email address. There can also be a catch all email as
before.
I don't like using two command line values for a single
argument, so what about putting them together, something like
-match 'proj1@xyz.com,somebody@abc.com:^/trunk/proj1'
The : is a separator between email addresses and the regex.
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).
2) commit_email.pl doesn't handle renames really nicely. Right
now they look like this:
Author: blair
Date: Fri, 28 Jun 2002 22:13:56 -0700
New Revision: 128
Added:
trunk/orca/packages/Digest-MD5-2.16/
trunk/orca/packages/Storable-1.0.13/
Removed:
trunk/orca/packages/Digest-MD5-2.13/
trunk/orca/packages/Storable-1.0.11/
Log:
To prepare to load orca-0.27b2 into trunk/orca, perform 2 renames.
* trunk/orca/packages/Digest-MD5-2.16: Renamed from
trunk/orca/packages/Digest-MD5-2.13.
* trunk/orca/packages/Storable-1.0.13: Renamed from
trunk/orca/packages/Storable-1.0.11.
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.
Best,
Blair
--
Blair Zajac <bl...@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
Re: commit_email.pl improvements
Posted by Branko Čibej <br...@xbc.nu>.
Blair Zajac wrote:
>Branko ?ibej wrote:
>
>
>>Blair Zajac wrote:
>>
>>
>>
>>>>I was thinking of command line length limits.
>>>>
>>>>
>>>>
>>>>
>>>I don't think we need to worry to much about this right now. We some
>>>some long command lines that compile svn. If people run into a problem,
>>>we can add it then.
>>>
>>>
>>>
>>*sigh*
>>
>>All the world is not Unix. Windows NT has a limit of, iirc, 128 chars on
>>the command line.
>>
>>
>
>Well, I don't know how long of a command line we need to support. I just
>tried writing a stupid .bat with a single echo in my Windows 2000 Pro box
>and it complained at 2048 bytes in a single command line. I don't see
>a script needing this many characters in a single call to commit-email.pl
>to support. If you think we do, then let me know.
>
>
I said Windows NT, not Windows 2000; the limits are different. Yes, I
think we definitely should support command lines longer then 128 chars.
Sure, there's no need to do that in the first iteration, but it'd be
nice to keep that in mind.
--
Brane Čibej <br...@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
Re: commit_email.pl improvements
Posted by Blair Zajac <bl...@orcaware.com>.
Branko ?ibej wrote:
>
> Blair Zajac wrote:
>
> >>I was thinking of command line length limits.
> >>
> >>
> >
> >I don't think we need to worry to much about this right now. We some
> >some long command lines that compile svn. If people run into a problem,
> >we can add it then.
> >
>
> *sigh*
>
> All the world is not Unix. Windows NT has a limit of, iirc, 128 chars on
> the command line.
Well, I don't know how long of a command line we need to support. I just
tried writing a stupid .bat with a single echo in my Windows 2000 Pro box
and it complained at 2048 bytes in a single command line. I don't see
a script needing this many characters in a single call to commit-email.pl
to support. If you think we do, then let me know.
Best,
Blair
--
Blair Zajac <bl...@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
Re: commit_email.pl improvements
Posted by Blair Zajac <bl...@orcaware.com>.
Blair Zajac wrote:
>
> Ben Collins-Sussman wrote:
> >
> > Branko Äibej <br...@xbc.nu> writes:
> >
> > > Blair Zajac wrote:
> > >
> > > >I was thinking to change the output of 'svnlook diff' to change the
> > > >output as previously mentioned, but this would be easier. How about
> > > >introducing a new symbol 'R' and then listing the new and old name in
> > > >the rename?
> > >
> > > That's what I was thinking, yes.
> >
> > Eep, right now the letter 'R' means "Replace" in our scheduling
> > output. Maybe something else.
>
> Is 'M' taken for 'Move'?
Or maybe use 'r' for 'rename' because 'M' is used for 'Modified' in
svn status. Are we keeping all the letters consistent between svn
status and svnlook?
Best,
Blair
--
Blair Zajac <bl...@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
Re: commit_email.pl improvements
Posted by Blair Zajac <bl...@orcaware.com>.
Ben Collins-Sussman wrote:
>
> Branko Äibej <br...@xbc.nu> writes:
>
> > Blair Zajac wrote:
> >
> > >I was thinking to change the output of 'svnlook diff' to change the
> > >output as previously mentioned, but this would be easier. How about
> > >introducing a new symbol 'R' and then listing the new and old name in
> > >the rename?
> >
> > That's what I was thinking, yes.
>
> Eep, right now the letter 'R' means "Replace" in our scheduling
> output. Maybe something else.
Is 'M' taken for 'Move'?
Blair
--
Blair Zajac <bl...@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
Re: commit_email.pl improvements
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Blair Zajac wrote:
>
> >I was thinking to change the output of 'svnlook diff' to change the
> >output as previously mentioned, but this would be easier. How about
> >introducing a new symbol 'R' and then listing the new and old name in
> >the rename?
>
> That's what I was thinking, yes.
Eep, right now the letter 'R' means "Replace" in our scheduling
output. Maybe something else.
> (We really should think a bit more about the diff format, though. What
> we generate now can't be pushed at patch, or even "svn patch" -- even
> if there was one.)
Yes... we should go back and look at that nice mail sent by Tom Lord
about developing an "enhanced" patch format that both svn and arch can
use. The only reason nobody has responded to that is because we've
all been too busy, I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: commit_email.pl improvements
Posted by Branko Čibej <br...@xbc.nu>.
Blair Zajac wrote:
>>I was thinking of command line length limits.
>>
>>
>
>I don't think we need to worry to much about this right now. We some
>some long command lines that compile svn. If people run into a problem,
>we can add it then.
>
*sigh*
All the world is not Unix. Windows NT has a limit of, iirc, 128 chars on
the command line.
>>What you'd want to do is modify "svndiff changed" to generate the
>>renames for you.
>>
>>
>
>I was thinking to change the output of 'svnlook diff' to change the
>output as previously mentioned, but this would be easier. How about
>introducing a new symbol 'R' and then listing the new and old name in
>the rename?
>
>
That's what I was thinking, yes.
(We really should think a bit more about the diff format, though. What
we generate now can't be pushed at patch, or even "svn patch" -- even if
there was one.)
--
Brane Čibej <br...@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
Re: commit_email.pl improvements
Posted by Blair Zajac <bl...@orcaware.com>.
Branko ?ibej wrote:
> 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.
The next -m will clear the -l, -r and any email addresses.
> >>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.
I don't think we need to worry to much about this right now. We some
some long command lines that compile svn. If people run into a problem,
we can add it then.
>
> What you'd want to do is modify "svndiff changed" to generate the
> renames for you.
I was thinking to change the output of 'svnlook diff' to change the
output as previously mentioned, but this would be easier. How about
introducing a new symbol 'R' and then listing the new and old name in
the rename?
Blair
--
Blair Zajac <bl...@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
Re: commit_email.pl improvements
Posted by Branko Čibej <br...@xbc.nu>.
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 <br...@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
Re: commit_email.pl improvements
Posted by Blair Zajac <bl...@orcaware.com>.
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 <bl...@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
Re: commit_email.pl improvements
Posted by Branko Čibej <br...@xbc.nu>.
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.
> 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
> 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.
>2) commit_email.pl doesn't handle renames really nicely. Right
> now they look like this:
>
> Author: blair
> Date: Fri, 28 Jun 2002 22:13:56 -0700
> New Revision: 128
>
> Added:
> trunk/orca/packages/Digest-MD5-2.16/
> trunk/orca/packages/Storable-1.0.13/
> Removed:
> trunk/orca/packages/Digest-MD5-2.13/
> trunk/orca/packages/Storable-1.0.11/
> Log:
> To prepare to load orca-0.27b2 into trunk/orca, perform 2 renames.
>
> * trunk/orca/packages/Digest-MD5-2.16: Renamed from
> trunk/orca/packages/Digest-MD5-2.13.
> * trunk/orca/packages/Storable-1.0.13: Renamed from
> trunk/orca/packages/Storable-1.0.11.
>
>
> 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.
--
Brane Čibej <br...@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
Re: commit_email.pl improvements
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> Please note my last sentence. I think it would be a good idea if
> the config (which is very close related to the repos) would be
> dumped/loaded when the repos is dumped/loaded. Therefore I would
> prefer to put it there. But of course, passing it on the command
> line the admin could decide where to put it (and therewith whether it
> would be dumped/loaded). Maybe it would be even better to split the
> config into two parts: /path/to/repo/conf/foobar.ini would contain
> stuff which is not related to a specific revision/branch like
> email-adresses. /path/to/repo/conf-versioned/foobar.ini would contain
> stuff which is closely related to a branch/revision like the
> regression tests which need to be run. Both directories should be
> dumped/loaded along with the repos.
(This is getting to be another thread entirely...)
The dumper is about dumping the filesystem's contents, nothing else.
It's an fs dump, not a repos dump. It's not about backups, or
transporting whole repositories from place to place.
If you wanted a script to do that, that script would probably use the
dumper/loader to do part of its job.
> > > BTW: Are there already config-files defined for the repos/conf
> > > directory? Does any description exist on those files?
> > I don't think there are any yet.
>
> Maybe the time has come to fill them up. I have a long list of ideas
> what we could put into those files ;-)
I don't mean to be overly harsh, but ideas are not exactly rare around
here. It's more important for us to decide what *not* to implement
than decide what to implement. In other words, please look at the
issues database and consider solving some of those problems, rather
than adding new potential bug sources :-).
I'm not saying ideas are bad, but ideas without code are not going to
be very compelling right now. We have too much to do for Alpha, and
then Beta, ... and then 1.0.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: commit_email.pl improvements
Posted by Josef Wolf <jw...@raven.inka.de>.
On Wed, Jul 03, 2002 at 05:09:53PM -0500, Karl Fogel wrote:
> Josef Wolf <jw...@raven.inka.de> writes:
> > For this the Config::IniFiles module could be used. Even if not: to
> > build a parser for ini-files is a trivial task in perl. The real
> > question is: where should the config file go? In the conf-directory of
> > the repos? Is it guaranteed that commit-email.pl can access this file
> > on the local filesystem? Are the contents of this directory
> > dumped/loaded when the repos is dumped/loaded?
>
> How about: the location of the conf file should be passed to
> commit-email.pl on its command line.
Please note my last sentence. I think it would be a good idea if
the config (which is very close related to the repos) would be
dumped/loaded when the repos is dumped/loaded. Therefore I would
prefer to put it there. But of course, passing it on the command
line the admin could decide where to put it (and therewith whether it
would be dumped/loaded). Maybe it would be even better to split the
config into two parts: /path/to/repo/conf/foobar.ini would contain
stuff which is not related to a specific revision/branch like
email-adresses. /path/to/repo/conf-versioned/foobar.ini would contain
stuff which is closely related to a branch/revision like the
regression tests which need to be run. Both directories should be
dumped/loaded along with the repos.
> > BTW: Are there already config-files defined for the repos/conf
> > directory? Does any description exist on those files?
> I don't think there are any yet.
Maybe the time has come to fill them up. I have a long list of ideas
what we could put into those files ;-)
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: commit_email.pl improvements
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> For this the Config::IniFiles module could be used. Even if not: to
> build a parser for ini-files is a trivial task in perl. The real
> question is: where should the config file go? In the conf-directory of
> the repos? Is it guaranteed that commit-email.pl can access this file
> on the local filesystem? Are the contents of this directory
> dumped/loaded when the repos is dumped/loaded?
How about: the location of the conf file should be passed to
commit-email.pl on its command line.
:-)
> BTW: Are there already config-files defined for the repos/conf
> directory? Does any description exist on those files?
I don't think there are any yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: commit_email.pl improvements
Posted by Josef Wolf <jw...@raven.inka.de>.
On Wed, Jul 03, 2002 at 03:13:40PM -0500, Karl Fogel wrote:
> If we're going to do this, we might as well match the client-side
> configuration file formats.
>
> [sectionname]
> regexp = "blah"
> mail = blah@blah
> reply-to = blorg@blorg
> etc = and so on
>
> The sectionname would be just some human-mnemonic tag for this project
> or subproject, so that the commit mailer would have a name for "item"
> in the file -- it could use that name in messages, for example.
This would be even better.
> (That also avoids quoting problems, such as regexps with square braces
> in them.)
Yupp...
> Oh. Of course, then we can't reuse our C code. We'd have to either
> a) find a config parser in Perl, or b) rewrite commit-email.pl in
> Python. Hmmm :-).
For this the Config::IniFiles module could be used. Even if not: to
build a parser for ini-files is a trivial task in perl. The real
question is: where should the config file go? In the conf-directory of
the repos? Is it guaranteed that commit-email.pl can access this file
on the local filesystem? Are the contents of this directory
dumped/loaded when the repos is dumped/loaded?
I think I should take a close look at commit-email.pl in the near
future. But before I can get into this I have to set up my ssl-enabled
svn server...
BTW: Are there already config-files defined for the repos/conf
directory? Does any description exist on those files?
> > BTW: while at the hooks, I want to suggest an other change. It would
> > be nice if the start-commit-hook and pre-commit-hook would get their
> > stdin/stdout redirected to a terminal(ssh?)-session to the committer
> > so the script could ask questions like "Regression-test failed! Do you
> > really want to commit (y/n)?" instead of just fail (and therefore
> > reject the commit).
>
> Um, that would be a pretty messy thing. Not saying it couldn't be
> done, but you'll probably have to provide the code if you want to see
> it anytime soon :-). Raises all sorts of questions, like what is the
> protocol between the client and the server (and just because you can
> get http through doesn't necessarily mean you can get anything else
> through)...
I have not thought about the concrete implementation. It was
meant only as a suggestion which should find its way onto the
[todo|wish]-list for some after-1.0 release. I just feel that
the hooks could be much more powerfull if they could act with
more flexibility than just say "allowed"/"rejected".
Maybe we could put this on the todo-list for some after-1.0 version?
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: commit_email.pl improvements
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> > % commit_email.pl ${REPOS} ${REV} \
> > -match '^/(trunk|tag|branches)/proj1/' proj1@xyz.com \
> > -match '^/(trunk|tag|branches)/proj2/' proj2@abc.com
> > catchall@abc.com
>
> Those lines can get very long and would be awesome to maintain.
> What about a config file which looks like:
>
> [^/(trunk|tag|branches)/proj1/]
> mail proj1@xyz.com
> log proj1.log
> reply-to proj1-list@xyzuu.com
>
> [^/(trunk|tag|branches)/proj2/]
> mail proj2@abc.com
> log proj2.log
> reply-to proj2-list@xyzuu.com
If we're going to do this, we might as well match the client-side
configuration file formats.
[sectionname]
regexp = "blah"
mail = blah@blah
reply-to = blorg@blorg
etc = and so on
The sectionname would be just some human-mnemonic tag for this project
or subproject, so that the commit mailer would have a name for "item"
in the file -- it could use that name in messages, for example.
(That also avoids quoting problems, such as regexps with square braces
in them.)
Oh. Of course, then we can't reuse our C code. We'd have to either
a) find a config parser in Perl, or b) rewrite commit-email.pl in
Python. Hmmm :-).
Personally, I'm not sure the long lines are a problem, and think we
might do best to avoid making a new config file until we're sure we
need it, though.
> BTW: while at the hooks, I want to suggest an other change. It would
> be nice if the start-commit-hook and pre-commit-hook would get their
> stdin/stdout redirected to a terminal(ssh?)-session to the committer
> so the script could ask questions like "Regression-test failed! Do you
> really want to commit (y/n)?" instead of just fail (and therefore
> reject the commit).
Um, that would be a pretty messy thing. Not saying it couldn't be
done, but you'll probably have to provide the code if you want to see
it anytime soon :-). Raises all sorts of questions, like what is the
protocol between the client and the server (and just because you can
get http through doesn't necessarily mean you can get anything else
through)...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: commit_email.pl improvements
Posted by Josef Wolf <jw...@raven.inka.de>.
On Mon, Jul 01, 2002 at 05:09:07PM -0700, Blair Zajac wrote:
> Several things I want to do with commit_email.pl. Feedback needed.
> % commit_email.pl ${REPOS} ${REV} \
> -match '^/(trunk|tag|branches)/proj1/' proj1@xyz.com \
> -match '^/(trunk|tag|branches)/proj2/' proj2@abc.com
> catchall@abc.com
Those lines can get very long and would be awesome to maintain.
What about a config file which looks like:
[^/(trunk|tag|branches)/proj1/]
mail proj1@xyz.com
log proj1.log
reply-to proj1-list@xyzuu.com
[^/(trunk|tag|branches)/proj2/]
mail proj2@abc.com
log proj2.log
reply-to proj2-list@xyzuu.com
BTW: while at the hooks, I want to suggest an other change. It would
be nice if the start-commit-hook and pre-commit-hook would get their
stdin/stdout redirected to a terminal(ssh?)-session to the committer
so the script could ask questions like "Regression-test failed! Do you
really want to commit (y/n)?" instead of just fail (and therefore
reject the commit).
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org