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

Re: file: Access vs. Database stability

From: Jens-Uwe Mager <jum_at_anubis.han.de>
Date: 2004-04-06 10:36:01 CEST

On Mon, Apr 05, 2004 at 22:06 -0500, C. Michael Pilato wrote:

> Not every tool that accepts a filesystem path should also accept a
> file:/// URL of that path. ViewCVS is a CGI script whose
> configuration does happen to allow you to specify a filesystem path to
> your repository (which works really well) or a URL to a repository
> (which uses the RA layer, and doesn't work so wonderfully).

Well, that one was hidden away not to be seen anywhere. I just tried it
and it works reasonably with http: urls, and thus I have one utility
less using direct file access. This is surely progress, thanks.

> Mailer.py is written to be a server-side hook script, called by
> post-commit with exactly the ${REPOS} argument provided to that script
> by Subversion itself. Allowing a program like this to accept is URL
> is silly, and will only lead to folks assuming that URLs other than
> file:/// ones would be supported. Which, of course, they won't.

I agree that mailer.py is a bit special, although I have some gripes
with using the REPOS directly. I would really like to be able to let
users configure themselves on what path elements they would like to
receive emails. For example specify in your home directory a .svntrigger
file with path wildcards and a shell script what to do. Executing the
shell script with the users privileges is easy, but letting the script
access the data mailer.py has access to (like the diff et. al.) is
difficult.

-- 
Jens-Uwe Mager	<pgp-mailto:F476EBC2>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 10:36:22 2004

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.