[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: commit_email.pl improvements

From: Josef Wolf <jw_at_raven.inka.de>
Date: 2002-07-03 23:43:54 CEST

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.)


> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.