On 14 aug 2013, at 03:25, Ben Reser <b...@reser.org> wrote:
> 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
I know, and yes, it can be used with this enhancement in form 2 and 4, but not
in form 1 and 3.
>
>> 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.
Ok
> 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.
Yes, I agree with that. There really is no reason to have '%' characters in the
path on servers. Minimal option proliferation... (None)
> 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.
Good
> 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.
The mod-vhost syntax is not quite as future proof though. I personally prefer
the mod-ssl syntax that Mike went with.
> 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
Makes sense.
Regards,
Thomas Å.
