Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

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.
Received on 2017-07-19 13:17:53 CEST