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