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

Re: svn commit: r1440047 - /subversion/trunk/subversion/tests/libsvn_repos/repos-test.c

From: Ben Reser <ben_at_reser.org>
Date: Tue, 29 Jan 2013 11:47:50 -0800

On Tue, Jan 29, 2013 at 10:40 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> I think there might be third party implementations (CollabNet, WANdisco, VisualSvn) that might rely on these values?
> So maybe somebody wants to respond?
> Personally I would prefer to see an error somewhere in SVN_ERR_AUTHZ to at least allow determining which subsystem produced the error code programmatically. (I don't maintain code connected to this)

The existing implementation returned non SVN_ERR_AUTHZ_* values even
though the documentation suggested otherwise. For example calling
svn_repos_authz_read() with must_exist on a non-existant file will
return ENOENT (or for that matter whatever error apr_file_open()

If we want SVN_ERR_AUTHZ specific error codes we can add them but
changing what I changed today will only change the error codes for the
in repo files. We'd have to catch a bunch of errors from
svn_config_read2() to have SVN_ERR_AUTHZ_* specific error codes for
the file paths.

Looking now I don't think I should have used
SVN_ERR_RA_LOCAL_REPOS_NOT_FOUND. Interestingly enough
svn_ra_local__split_URL() doesn't even use it itself. It uses
SVN_ERR_RA_LOCAL_REPOS_OPEN_FAILED for both the search for the
root_path and for the actual open. I should have just created

I'd be happy to add SVN_ERR_AUTHZ_REPOS_ENOENT and
SVN_ERR_AUTHZ_REPOS_ENOTDIR (or something to that effect). But I'm
not sure it's really worth it, since they would only apply to the in
repository files and would create the impression that you're always
going to get an SVN_ERR_AUTHZ_* error.
Received on 2013-01-29 20:48:31 CET

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.