Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4691

Optional Read-only attrs to be the same as the user's ability to commit changes back



    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:



      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.


      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.




            • Assignee:
              paul Paul Hammant
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: