On Fri, Jan 25, 2013 at 2:30 AM, Philip Martin <[email protected]> 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.
