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
Received on Sun Dec 25 01:16:26 2005