On Fri, Jan 25, 2013 at 2:30 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Are administrators going to want both relative path and absolute path
> versions of this directive?
If you want repo unique groups you can just put it in authz file and
not use this directive. So I kinda doubt there's a use for the repos
relative directive. I guess the exception would be if you wanted to
share some groups between repos and not with other repos.
That said, it shouldn't be that hard to add the repos relative option
and just have it in case anyone wants it.
> I wonder if we should implement some sort of generic include mechanism
> instead. Trac uses an INI compatible mechanism:
>
> [inherit]
> file = path/to/another/file
>
> we could
>
> [inherit]
> file = path/to/another/file
> relative_file = path/to/another/file
If we go down this route we have a couple of things to deal with:
1) Where would we root the relative paths? http and svnserve have
different ideas of the root for relative paths.
AuthzSVNReposRelativeAccessFile helped by making the most common root
for svnserve available to http as well, but it doesn't really solve
the problem. http roots the files either in the ServerRoot
(AuthzSVNAccessFile) or in the conf dir of the repository
(AuthzSVNReposRelativeAccessFile). svnserve roots the files relative
to the directory which svnserve.conf is located in, which if you
aren't providing --config-file is the conf dir of the repository. I
suppose the best thing to do is root them in the repositories conf
directory.
2) Doing this means pushing the relative path root into the
svn_repos_authz_* functions since the repository layer doesn't know
the full context. As it is I feel like how I added the repos_root
argument in there is almost wrong and have thought about removing it
and making the servers have to resolve the repository relative paths
themselves (similar to how the cmdline client has to resolve
repository relative paths before handing them to libsvn_client).
Unlike the repos_root argument there's really no way to get rid of the
ugliness of passing the root for included paths in.
3) Within svnauthz you'll have to allow the relative root to be set
from the command line since it also won't have the context from the
server. Thus adding more arguments to a command and making it less
intuitive.
4) We parse the authz files as just Subversion conf files (basically
ini files). It's not until the conf is loaded into memory that we
process it as an authz file. You couldn't put an [include] anywhere
in the file and have it override things that were already set but not
override things that hadn't been set. You'd have to say that includes
override anything that is set. While it would be functional it just
wouldn't be intuitive. So if we didn't like that it'd mean writing a
new parser.
Obviously we can deal with these things but it becomes a lot messier
than what he's done right now.
Received on 2013-01-28 17:03:51 CET