[
https://issues.apache.org/jira/browse/SVN-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104802#comment-16104802
]
Bert Huijben commented on SVN-4691:
-----------------------------------
Food for thought: When would the read-only status of these files be updated
after the initial checkout?
With a change to the svn:needs-lock property the client can see when the
property is added or removed and then apply the per-file status specifically.
If somebody changes the authz settings on the server there is no such thing and
the client can't see something has changed. Going over each and every file on
every update -which we now avoid- would be very expensive. And even then the
status could be out of date any moment after the update.
For lock this scenario is handled by the lock operation on the server, and the
commit failing if somebody else has the lock.
> 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)
