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

Re: Relative behaviours of authz in mod_authz_svn and svnserve

From: <kfogel_at_collab.net>
Date: 2005-10-10 22:43:09 CEST

Greg Hudson <ghudson@MIT.EDU> writes:
> On Mon, 2005-10-10 at 15:08 -0500, kfogel@collab.net wrote:
> > Well, it's not a matter of "choosing" 1. The behavior which 1
> > proposes to document is already present in Subversion.
>
> Not in a release. (For svnserve. As I understand it, option 2 would
> represent an incompatible change in svnserve behavior, but not in
> mod_dav_svn behavior since right now the parentpath-relative
> specification of a repository has to be a single path component.)

Urgk. Good point.

Okay, how about a compromise solution to avoid compatibility problems?
David's original description of 2 was:

> 2. Make mod_dav_svn and mod_authz_svn handle n-depth repositories
> when serving SVNParentPath, and make svnserve handle n-depth
> authz like it should. This makes svnserve and mod_dav_svn serve
> repositories equally, and enables both having the same authz
> rules and general setup if the repositories have to be served
> from both RA methods.

What if we break that into two parts:

  2a. Make svnserve handle n-depth authz like it should.

  2b. Make mod_dav_svn and mod_authz_svn handle n-depth repositories
      when serving SVNParentPath.

For 1.3, we'd only do 2a, which I think is not a very hard change. 2b
we'd save for 1.4, and in the interim we'd document the inconsistency.

Thoughts?

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 10 23:54:53 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.