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)
