[jira] [Created] (SVN-4691) Optional Read-only attrs to be the same as the user's ability to commit changes back

["Paul Hammant (JIRA)" <ji...@apache.org>]

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)