For my file-sync tech, I want to flip readonly bits within the filesystem when I Curl-GET resources down from Svn. While mod_authz_svn adjudicates on where a) resources are readable by the user in question and b) whether writable.
If an item were readable, but not writable, the only way the end-user would know that is in an *attempt to* commit (regular Svn client), or PUT (SVNAutoversioning on). It's vetoed then. I'm *not* advocating the changing of the Subversion client's default behavior, but it would be great for the information about writability for that user were passed to the client as part of the retrieval of the resource. Specifically, I am advocating for a new response HTTP header to be added. There's no standard header <https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Response_fields> for 'this resource is read-only'. Probably because the original intent of the web was that everything was read-only and write only came with DAV (HTTP 1.1; Greg Stein and a committee). Anyway, I'm proposing that mod_authz_svn adds a header as the resource is sent to the client. My sync agent will flip the read-only bits on the client copy, and continue to sync the resource from Svn if it changes and as expected (also noting if it becomes writable for that user later on). Secondarily, I would expect Subversion's client to gain a new option: --make-workingcopy-resources-readonly-if-applicable Thoughts? After a conversation here, I'd like to raise a feature request in Jira for this. I understand this conversation to be a pre-requisite to that.