[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Syntax for templated SVNPath

From: Thomas Åkesson <thomas_at_bafast.se>
Date: Wed, 14 Aug 2013 23:55:48 +0200

On 14 aug 2013, at 03:25, Ben Reser <ben_at_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.


> 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.


> 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.

Thomas Å.
Received on 2013-08-14 23:56:23 CEST

This is an archived mail posted to the Subversion Dev mailing list.