On Fri, 6 Jan 2006, Lieven Govaerts wrote:
> Maybe your remarks were outside the initial scope we intended for this
> discussion, let me clarify that first.
Yep, no doubt; and not worth holding up this proposal if others like it.
My experience has been that this direction heads down a path of other
desired features, where each step feels natural and easy, but after a
dozen iterations ends up with something powerful but complicated.
> Do you think both paths can/should be followed in parallel? I'm willing to
> further discuss functionality of the LDAP authorization part. Maybe you can
> explain or give pointers to documents explaining how the CollabNet solution
> works?
It's not in a nicely documented form, really; the basic premise is that
we've got three dimensions: users, projects (which each get a separate SVN
repos, separate bug database, and other separate databases for other
tools), and permissions. Permissions are just functions that the tool
tells the auth system it will watch for - "checkout", "commit", "tag",
apply to SVN, for example, but not to bug tracking. I can create groups
along any of those three dimensions - user groups, project groups, and
permission groups which are more simply known as "roles". Then you grant
a particular user or group of users a role on a single project or
collection of projects. "Domain" owners can create domain-wide roles and
grant them across any project. Project owners have the ability to create
project-specific roles and grant those (or the domain-wide defined roles)
roles for their own projects. There's also inheritance, where one project
is a subproject of another. We don't yet have one role being a derivative
of another or things like that. Some permissions can be scoped based on a
regular expression that applies to a path - for example, you could give
"interns" the rights to commit to "/branches/experimental" across a group
of projects, or even "documentation writers" the rights to commit to
"*.html|*.doc|*.pdf".
Sounds like overkill, but it became clearly necessary once you started to
talk about organizations with more than a couple dozen developers and more
than one or two projects underway simultaneously. We slid down a looong
slope. :)
We've hesitated to open this up partly on the assumption that eventually a
standard would emerge for doing this kind of thing in a cross-tool way,
something we could move to rather than push this as a proprietary thing.
That hasn't yet happened and I wonder if, as David noted, it's because
people always solve it specific to their application (I see some content
management systems have it, for example) and not in a generic way the way
LDAP works.
Part of it might be the heavy UI implied by all that flexibility and
management... so any common system would necessarily imply applications to
manage that data, and thus you get something PHP-specific, or
Java-specific, or whatever.
Ours is implemented in Java and would require people to run a JavaVM in
parallel with SVN; and its UI is rendered as servlets, etc etc.
Streamlining our own system down to a separable module would be yet
another hurdle before we could open it up. But if there's the chance that
others would use and contribute to it...
Thanks for the feedback,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 7 03:52:39 2006