Re: Syntax for templated SVNPath

On 9 aug 2013, at 17:52, C. Michael Pilato <cmpilato_at_collab.net> wrote:

> Put simply, CollabNet wants to start using dynamic virtual hosting with
> Apache HTTP Server in one of our offerings in order to avoid adding a
> literal <VirtualHost> block for every single virtual host on the system.

First of all, I like this enhancement, a lot.

> There are obviously many configuration settings which are common across
> all the virtual hosts, but there are some which need to vary for each
> host. One of the latter is the path of the Subversion repository parent
> path, because each vhost keeps its own collection of repositories.

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.

>
> The solution I developed for this on the SVNParentPathTemplate branch is
> to introduce a new mod_dav_svn directive which is like SVNParentPath,
> but where you can insert the string "%{SERVER_NAME}" into the path
> specification and have mod_dav_svn replace that at runtime with the
> server name of the virtual host by which the request came in. For example:
>
> SVNParentPathTemplate /usr/local/svn/%{SERVER_NAME}/repositories
>
> So Daniel, Ben and I were talking in #httpd-dev about the proper syntax
> for my new directive, because I wanted to use something that matches
> conventions used by other httpd modules rather than trying to break new
> syntax ground here. (I preferred to use a named variable instead of
> "%s" or "1" or somesuch with future expansion in mind.)

I like the choice of syntax, makes sense in httpd config and it's expandable, see related issue below.

> But along the way, our conversation led us to the problem of option
> proliferation, precisely because we might someday also add
> SVNPathTemplate (the not-parent form of my new thing), or an
> SVNVirtualPath/SVNVirtualParentPath pair (which behaves more like
> mod_vhost_alias's directives), etc. And we sighed and proactively
> dreamt of days when configuring Subversion was simpler.

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.

> The discussion you are now privy to is all about how we can make our
> option set both useful and expandible to account for these immediate and
> future-maybe scenarios.

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.

Thanks,
Thomas Å.
Received on 2013-08-14 01:41:56 CEST