Re: 1.8 new public API review (mostly) complete.

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 <danielsh_at_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.
Received on 2013-04-01 18:30:58 CEST