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

Re: svn commit: r1064093 -/subversion/trunk/subversion/libsvn_repos/authz.c

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 28 Jan 2011 06:21:34 +0200

C. Michael Pilato wrote on Thu, Jan 27, 2011 at 15:33:17 -0500:
> On 01/27/2011 02:18 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Thu, Jan 27, 2011 at 14:14:11 -0500:
> >> If we have have the option of moving towards case-sensitivity -- that is, a
> >> *more*-precise authz policy -- that seems like a good thing. I'd even be in
> >> favor of making this behavior optional (like the force_username_case option
> >> we already have).
> >>
> >
> > Could you clarify? What modes are you suggesting to support, and which
> > would be the default one?
>
> Well, I was thinking about "authz-section-case-sensitive = true|false" in
> svnserve.conf, and "SVNAuthzSectionCaseSensitive on|off" for the DAV
> modules. Enabling this gives us case sensitivity in our treatment of those
> authz section names (which include repository names and paths); disabling
> makes it case-insensitive.
>
> But I confess that I'm only considering this as a way to avoid breaking
> existing authz files that are exploiting the case-insensitivity we have
> today. If we all agree that case-*sensitivity* (or case-insensitivity) is
> The Way To Go, and that the realistic user effect of consistification here
> is negligible, then toss the "make it optional" suggestion altogether.
>

I've already expressed my opinion (+1 to casefulness), so I'll let
others chime in now.

In any case, is anyone interested in writing a patch in this direction
(once we agree what the direction is)?

/me looking at Arwin

> > Also: where is force_username_case documented? The default
> > svnserve.conf doesn't mention it.
>
> Really?

No, sorry.

(I used my new-test-repository script instead of plain 'svnadmin create'.)
Received on 2011-01-28 05:26:03 CET

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.