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
Received on Wed Jul 3 22:23:18 2002