Paul Hammant created SVN-4691: --------------------------------- Summary: Optional Read-only attrs to be the same as the user's ability to commit changes back Key: SVN-4691 URL: https://issues.apache.org/jira/browse/SVN-4691 Project: Subversion Issue Type: Improvement Reporter: Paul Hammant Priority: Minor
*+Context+* Consider a resource in a Subversion path/to/resource.txt and two users SammySuper and RogerReadOnly. SammySuper can read and change path/to/resource.txt, because of permissions set in the applicable AuthUserFile (mentioned in Apache's <Location /svn> block). Similarly, RogerReadOnly can read, but CANNOT change path/to/resource.txt because of DIFFERENT permissions in that AuthUserFile file. Specifically, RogerReadOnly can change the file locally to him, but cannot commit that back to Subversion successfully. There is a third category: unauthenticated (anon) users - who can read resources, including path/to/resource.txt but cannot change anything on subversion in a commit operation. All of the above works today. *+Feature Request - new 'svn' command option.+* I am proposing a new command line option --percolate-read-only-attribute (or similar) that changes the nature of the working copy created in a checkout (or update) situation. If 'svn --percolate-readonly-attribute co URL' were performed: SammySuper's experience would be unchanged. RogerReadOnly would additionally encounter path/to/resource.txt in his working copy as write protected. In other words the "Read Only" bit/attr would have been set in an OS dependent way. RogerReadOnly could, of course, un-set that attr/bit but this feature request is about taking what the server knows and applying it to the working copy on the client. The unauthenticated/anon users, with the --percolate-read-only-attribute option added to checkout/update, would experience *all the files in the working copy* set to read-only. *+This is not at all satisfiable with the versioned property svn:needs-lock+* Ref: http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html#svn.advanced.locking.lock-communication This is wholly different. All users would encounter the item as read-only. I'm not wanting that. I'm wanting read-only obeying the fine grained user and group potential of the AuthUserFile permissions. Specifically - different people will encounter the same resource as writable or read only. *+Confession+* I myself am using Python's requests library to PUT/GET resources to/from Subversion. I would pluck out the option from the XML of the response or header. I would also pass up whatever was required to enable it in the request. I'd reverse engineer the wire if needs be. However, I believe this to be just as useful to the regular subversion client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)