Re: ACL design question

Branko Čibej wrote:
> Helge Jensen wrote:

> Note that a real ACL implementation can't use properties, for two reasons:
>
> * you have to be able to change the ACL of a historic revision
> * ACLs must be attached to the path, not the node version (like
> properties do), and more than one path can refer to the same node
> varsion.

Could you elaborate on where/why this is nessesary? or point me to
litterature on this.

I can envision a problem if you wish to limit _reading_, but I thought
properties could do just fine for the WRITE scenario. Since you cannot
change the historic versions, only commit new ones and here, then the
"current" ACL (the set of acl:write properties on rHEAD) will apply to
commits.

"svnadmin setlog" seemingly does changes to old versions, but "svnadmin"
should not be limited by any ACL.

A possible way to extend the property solution to cover the reading
scnario would be to combine the HEAD and requested revision property,...
I havent given it much thought since it has not been requested by my
users yet.

Note, that if i do an svn copy of something protected by an acl (I can
only copy to a place where i have write permissions), I am able to
remove the acl:write property on what I copied, which means I am able to
"take ownership" of copies.

The property solution works pretty well here. And people are able to
give away permissions to each-other for any path where they have
permissions themselves, it's really very low on administration interaction.

-- 
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org