Paul Hammant wrote:
> May I go ahead and raise the feature request in Jira now?
Thanks for discussing here so far. Yes you may file it.
In order for it to progress to acceptance you probably also need to
clarify and finish discussing. It sounds like you have a clear idea of
what you want but it's not quite so clear to me. I'm not at all close to
the server side, especially client-less use cases, so I might well miss
the bigger picture.
For example, in my reply that you quoted below, I suggested your
rationale didn't make sense and suggested instead my own rationale that
"a polite system ought to inform the user what they can and cannot do"
-- in other words it's about helping the users not the admins.
Also how does this relate to authenticated read access vs.
unauthenticated (anonymous) read access? Could some useful indicator be
given even in the anonymous case?
Your thoughts please?
- Julian
> I believe the approved process was discuss on mail-list, then raise in Jira.
>
> - Paul
>
> On Fri, Jul 21, 2017 at 5:40 AM, Julian Foad <julianfoad_at_gmail.com
> <mailto:julianfoad_at_gmail.com>> wrote:
>
> Paul Hammant wrote:> It will help the owners of subversion repos
> preventing files from being> overwritten that they do not want to be
> overwritten. [...]
> >
> > It will help subversion end-users not upset the owners of repositories
> > by changing files (and committing them back) that there are not
> supposed to.
>
> I kind of like your suggestion in general terms -- because a polite
> system ought to inform the user what they can and cannot do, before they
> waste time trying it -- but I don't understand your reply here.
>
> In your original message you wrote "mod_authz_svn adjudicates". These
> authz rules are strict: a user cannot override them from their side.
>
> > Secondarily, I would expect Subversion's client to gain a new option:
> >
> > --make-workingcopy-resources-readonly-if-applicable
>
> The "svn:needs-lock" property for "advisory locking" causes the
> Subversion client to make files read-only in the WC when the user
> doesn't have the corresponding lock. See
> <http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
> <http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html>>. A
> user can override ("break") this kind of lock if they want to.
>
> That mechanism is usually used for files for which the user, or *some*
> users, have write access. I suppose files which are authz-read-only for
> the current user, could also be marked read-only in the WC regardless of
> whether they have svn:needs-lock. That sounds reasonable to me so far.
Received on 2017-07-25 17:38:10 CEST