[
https://issues.apache.org/jira/browse/SVN-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104905#comment-16104905
]
Paul Hammant commented on SVN-4691:
-----------------------------------
Question - how does a change to AuthUserFile settings normally impact
"subversion update" ?
Scenario: Yesterday I was not authorized at all to foo/bar/ and my checkout
didn't have it. Today I was granted R+W access, and I do an 'svn up'. What are
my expectations?
> 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)
