Here's the current doc string of svn_repos_authz_read2(): /**
* Read authz configuration data from @a path (a file, repos relative * url, an absolute file url, or a registry path) into @a *authz_p, * allocated in @a pool. * * If @a groups_path (a file, repos relative url, an absolute file url, * or a registry path) is set, use the global groups parsed from it. * * [...] If @a path is a repos relative URL then @a repos_root must be * set to the root of the repository [...]. svn_error_t * svn_repos_authz_read2(svn_authz_t **authz_p, const char *path, const char *groups_path, svn_boolean_t must_exist, const char *repos_root, apr_pool_t *pool); First we need to clarify what "@a path (a file,)" means. From the discussion below I gather "a file" means an absolute local filesystem path, so let's say so. Ben Reser wrote: > On Sun, Mar 31, 2013 at 5:58 AM, Daniel Shahaf <danie...@elego.de> wrote: >> How about forbidding PATH to be a repos-relative URL, but permitting it >> to be a relpath, that is then interpreted relative to the repos root. >> The conversion is trivial, just +2 on the argument, but it avoids Erm, not so trivial: svn_path_resolve_repos_relative_url() assumes the "repos-relative URL" is URI-encoded, whereas a relpath is by definition not URI-encoded. >> "non-canonical" and "^/ URLs" in the repos API. > > This could work because we don't accept a relative path for the OS > file system paths. The funny thing about this is then I don't think I > need the repos-relative APIs that I made public. That could work, but it is *much* nicer in my opinion to get rid of the relative-URL option and get rid of the 'repos_root' argument (which was Ben's original suggestion IIUC). It's simple, cheap, and easy. - Julian >> (I would say permit it to be an fspath, which is by definition absolute, >> but fspaths aren't part of the public API.) > > Not a good idean, on unix platforms the fspath would be > indistinguishable from an absolute OS file system path.
