Affects Version/s: None
Fix Version/s: None
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.
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 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.
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.