On Mon, 2003-11-24 at 02:11, Karl Chen wrote:
> When Subversion can't access a repository it doesn't give
> information as to why not. For example, if a grandparent
> directory needs chmod a+rx all you'll get is
>
> svn: Unsupported repository version
> svn: PROPFIND request failed on '/repos/quarl/trunk/bookmarks'
> svn:
> Expected version '2' of repository; found no version at all; is '/home/quarl/REPOS/quarl' a valid repository path?
I see a few problems here, the first two of which are the most
important:
(1) In repos.c:check_repos_version(), if we get any error reading the
format file, we wrap the "found no version at all" error around it,
which is a confusing message when the underlying error is anything other
than file-not-found. (Which, ironically, it will almost never be,
because the URL-splitting algorithm prevents us from trying a path which
doesn't contain a format file.)
(2) dav_svn_convert_err() only converts the topmost error of an error
chain. In this case, the important detail is in a lower-level error.
(3) Telling the user which HTTP request failed is of marginal value,
and it's pretty confusing to the user who isn't familiar with DAV and
DeltaV. The client's error message should stick to explaining the
problem in user's terms, i.e. that the given URL does not appear to have
been successfully configured as a Subversion repository.
(4) The topmost error code in the server's error chain
(SVN_ERR_REPOS_UNSUPPORTED_VERSION) floats to the top of the client's
error chain, and the generic message is displayed, when it has no
bearing on the problem. This case is more evidence that we should not
display generic error messages when we have specific ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 24 17:50:32 2003