On 8/13/13 4:41 PM, Thomas Åkesson wrote:
> To make this enhancement complete, I believe all settings that take a "directory-path" should be handled identically (allow the templating). To me, the most obvious example is "AuthzSVNAccessFile". It wouldn't make sense to separate repositories for different vhosts but keep a single huge access file.
This probably isn't what you're thinking of but
AuthzSVNReposRelativeAccessFile has been around since 1.7:
http://subversion.apache.org/docs/release-notes/1.7.html#per-repos-authz
> Agree, duplicating the directives is not the way to go. But deprecating SVNParentPath seems a bit over the top. SVNPath vs SVNParentPath are 2 quite distinct modes of operation and many many configs use them so I get the feeling SVNParentPath can't be removed for a long time anyway.
>
> I propose either of:
>
> 1. SVNPathTemplates on | off
> 2. SVNPathType default | template | ...
>
> Where the option applies to all SVN* options that take a pathspec, including the authz options.
My vote is to technically eliminate SVNParentPath (though it would still
be accepted, but we'd just treat it the same as SVNPath). svnserve
supports pointing things directly at the repository and at a parent
paths without the user needing to specify this, I can't see any reason
httpd needs this extra verbosity.
Further, I don't see a reason to toggle templates on or off. When we
added in repos authz I didn't worry about someone having a relative path
with starting with file: or ^, both of which would have been broken.
By the same account I don't think path names like %{SERVER_NAME} or %0
are worth worrying about.
Adding the verbosity only helps someone doing something that probably
doesn't make any sense and hurts the vast majority.
> I would like to throw in a related issue that I was thinking about while studying the release notes of svn 1.8. We (Simonsoft) are _very_ exited about the "In repository authz". In our setups, the access file (currently one per server) is managed in a separate repository, but we have to manually ensure the latest one is on disk (svn up). All our servers have an "admin" repo containing server config including the access file.
>
> We would like to transition to:
> - Separate access file for each repo.
> - Separate groups file (AuthzSVNGroupsFile)
> - Keep access files in admin repo.
> - Reference the access/group files using file://...
>
> However, there is a problem with referencing separate access files that way when using SVNParentPath. We would need the same templating concept:
> file:///path/to/admin-repo/%{REPO_NAME}/file
> or
> file:///path/to/%{SERVER_NAME}/admin-repo/%{REPO_NAME}/file
>
> This is somewhat out of scope for this discussion, but still a validation that the templating syntax can also address this limitation.
I remember thinking about doing this and decided not to. I don't really
see a huge problem with doing this.
While I like the human readable variable names like %{SERVER_NAME}, I do
wonder if we shouldn't make our virtual hosting patterns match that of
the mod_vhost_alias does, I can see at least some of the hostname
splitting being useful. I can also see someone using dynamic svn
virutal hosting also using mod_vhost_alias for websites. So some
existing domain knowledge could be reused by users.
If we use human readable variable names REPO_NAME should be
SVN-REPOS-NAME to match what we're using to allow logging. e.g.
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.logging
Received on 2013-08-14 03:26:05 CEST