On Thu, 2002-05-23 at 23:46, Glenn A. Thompson wrote:
> OK thats what I hoped you meant. Read can be exposed. Not write. But it was
> readable at 9 before anyway. I think this is reasonable and consistant.
Consistent, yes. Reasonable, no. You need to be able to retcon ACL's
when:
* You discover that you forgot to set a restrictive ACL on some
proprietary source you brought online last week.
* You hire someone new and need to give them read access to the change
history of the proprietary source code.
The latter problem can be solved if we implement a group system inside
Subversion (an ACL would point to a group, and the group could be
changed without changing the ACL itself), but man, that's a lot of hair.
One question is how important it is to record a history of ACL changes.
If it's not, we can simply provide an interface for changing properties
(or some concept which is "just like properties") on old revisions of a
node and have done with it.
If we do want to record a history of ACL changes, then a possible
solution is to have an acl file somewhere in the Subversion file space
(similar in principle to the Apache access control config file), and
then when you make a copy, the filesystem magically edits the acl file
so that the acl on the new node matches the acl on the old node. That's
kind of weird, though, and calls into question how things work when you
want to make a copy and edit the acl file at the same time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 24 05:55:32 2002