Re: Could svn_backend check permissions?

Tobias,

I'm a nobody too. We were definitely not discussion messing with
permissions. We were discussing where and how to throw an understandable error message
or to leave it to berkeley to display any error (not permission denied btw).

Greg Hudson, Mark and I advocated checking conditions so as to be sure that
if any db errors occur, that they are not due to inaccessability of the
database by berkeley. John said "there's nothing wrong with BDB and nothing with
our use of it, so we should do nothing. It's the users fault". (Ofcourse this
is what I understood their comments to be.)

So I think we agree to the solution we are currently persuing?

bye,

Erik.

> e.huelsmann@gmx.net wrote:
> > It seems like this patch is addressing another issue:
> > whether or not there is a repository. Our problem does not focus on the
> > existence of one, but on the accessibility in case one is found.
>
> That patch was about fixing ra_svn and ra_local to make sure that any
> error detected when opening the repository is sent upwards and displayed
> to the user.
>
> FWIW, I think that it's the wrong approach to mess with the permission
> of the files inside the db dir. If the permissions are wrong, BDB will
> throw an error. Subversion's mission is to show a nice and clear error
> message to the user so that (s)he can understand what the problem is and
> fix it.
>
> If there are places where subversion failes to spit out a nice
> "Permission denied" error message, those places should be fixed.
>
> If the "Permission denied" at the end of the current error message is
> not clear enough, it would be a simple matter to clarify it. It could
> even contain an URL to the FAQ.
>
> ...but I'm just a nobody, of course... :-)
>
> /Tobias
>

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org