Hi all!
I would like to know if this topic was reintroduced and put in
discussion again in the svn's developers circle after the release of
Subversion 1.3. If I could vote to this feature, I would give it +1.
In the case that regex are not be feasible in the short term,
wildcards are already a big step to be given towards authorization
file maintainability.
My two cents,
Cidral
2005/12/23, David Anderson <david.anderson@calixo.net>:
> Lieven Govaerts wrote:
> > Wait a few days till the devs ship 1.3 and then introduce it again :)
>
> Yes. :-)
>
> Also, once a complete proposal is put together, please send it to the
> development mailing list. Subversion developers aren't necessarily
> subscribed to the users list, as it is quite high trafic. I'm one still
> subscribed, and am rather interested. I built authz support into
> svnserve for 1.3.0, and have a few plans to expand authz somewhat. If
> this proposal is feasible (warning - there are problems), then it could
> be one of the things added.
>
> > No seriously. The use regular expressions in the authz_svn module has
> > been discussed on the dev list before, there's even been a patch
> > submitted to that list:
> > http://svn.haxx.se/dev/archive-2005-02/0631.shtml It wasn't accepted
> > though, and the author seems to have given up on it.
>
> Two thoughts on this. First of all, as Branko Cibej pointed out in his
> reply to that mail, the proposed patch implemented limited wildcard
> matching, and not regular expression support (which is usually taken to
> mean PCRE support).
>
> Secondly, this patch was written and proposed 11 months ago, when authz
> code was still solely in an apache module. This is no longer the case,
> as this summer I moved the authz algorithm code into the Svn repository
> library (libsvn_repos), and made both mod_authz_svn and svnserve (yes,
> the one serving svn:// stuff) use this new library code. This means
> that any proposal you make must now take into account that modifying
> authz is, in essence, altering one of the core Subversion libraries.
> So, things proposed in earlier discussions (tighter integration with
> Apache) are no longer possible, or only possible with very specific
> conditions. Please keep that in mind while putting a proposal together.
>
> > Last week I described on this list how regular expressions would help
> > me manage the 50+ projects we will have to maintain next year. ( see
> > http://svn.haxx.se/users/archive-2005-12/0887.shtml, the last 10
> > lines ).
>
> In that mail, you suggest regular expression matching, which I'll return
> to a little later, but also LDAP group integration. In the light of my
> previous statement, understand that this is not even contemplatable.
> Adding an LDAP dependency in a subversion core library is out of the
> question.
>
> However, to hint at a possible solution, the authz code in the core
> could be made to accept callbacks, which mod_authz_svn could use to hook
> some authz functions into stuff Apache can do (ie. LDAP lookups). That
> would make authz extendable and tailorable to the specific server using
> it (apache or svnserve).
>
> > We have two use cases for regular expressions: 1. wildcard matching
> > of paths, to allow groups automatic write access on all branches of
> > the same type.
>
> This is wildcard support on paths, and has already been considered and
> discussed. I can't remember if there were any obstacles to
> implementation, but note that apr_fnmatch exists and seems to provide
> shell-style wildcard matching, and could be used for this.
>
> > 2. capturing groups: reuse the name of the repository as prefix for
> > the group name, so not all 50 repositories have to be configured
> > individually.
>
> This is much more complex, and requires a fully fledged PCRE engine to
> perform. This means either adding another dependency to the Subversion
> core code, to support PCRE, or make this specific to apache as described
> above. I think that the latter is not really acceptable either, as PCRE
> support would be a fundamental change to the authz code, and should be
> shared across servers.
>
> As I said before, I am certainly not opposing this proposal, as the uses
> do exist and are cool. I am merely pointing out the new constraints
> that 1.3 code will bring to such changes, so that a proposal has better
> chances of being well received.
>
> > What are your or other peoples requirements? Would be nice to finish
> > a complete proposal here.
>
> Well, my requirement is to avoid, to any extent possible, the
> introduction of extra dependencies on external systems, and to consider
> any changes along with their impact, now that authz is core svn code.
> There are enough people complaining about the number of dependencies in
> Subversion without adding more :-).
>
> Also, a note on performance issues: avoid anything that would require
> systematically sieving large chunks of the authz configuration to be
> applicable. The current code is nice, in the sense that in many cases
> it can "bail early", having gotten sufficient information to make a
> decision without jumping through 90% of a 15k authz file. Don't worry
> too hard about it at this stage, we can get back to performance issues
> once a conceptual proposal is fleshed out, but keep it in mind if
> anything that is clearly cpu hungry comes up.
>
> If a consensus is reached with a proposal, I'd be willing to implement it.
>
> Regards,
> - Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 11 18:32:37 2006