subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <>
Subject Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'
Date Wed, 19 Jul 2017 11:17:44 GMT
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

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

Specifically, I am advocating for a new response HTTP header to be added.
There's no standard header
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:



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.

View raw message