[
https://issues.apache.org/jira/browse/SVN-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104987#comment-16104987
]
Bert Huijben commented on SVN-4691:
---
When you don't have access to some tree in your working copy, the server
notifies the client that there is a 'server-excluded' tree below that root. On
update the client sends a list of these server excluded nodes found in the
update tree as part of the update request. At that point the server can tell
you which parts of the tree are different.
So answering your question: on that update things might appear or disappear in
your working copy. Potentially causing conflicts.
Usually you don't see these server-excluded nodes using your svn client, but
they are kept in wc.db. In a similar way files that are deleted during a commit
("not-present") and depth excluded nodes ("user-excluded") as well. This all to
allow update to work as efficiently as possible, by only describing relevant
changes.
> 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
> 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)
