You are 100% correct.
For an anon svn-co (if allowed by the server), the default behavior should
be as is now - making working copy that is editable.
For an anon svn-co (if allowed by the server), the behavior if a new option
is specified - make the files readonly (Win and Unix derivatives)
For authenticated svn-co, the default behavior should be as is now - making
working copy that is editable.
For authenticated svn-co, tthe behavior if a new option is specified - make
the files readonly (Win and Unix derivatives)
That new option (on the CLI at least), would be one of
--percolate-readonly-attr --make-files-readonly-if-applicable --RO-bit-too
--only-writable-in-wc-if-writable-on-server-for-this-user-argghhh-this-is-a-bit-long
:)
I would Imagie Subversion would always impart the attr for each file to the
client, but the client only acts on it if
1. the right CLI option was specified
1.1 per command?
2. specified in the original checkout and remembered going forwards
3. subject to some policy on the server
4. subject to some --global policy
And yes, the Jira posting would need to be a distillation of all of the
rolled up thought and common wisdom on this thread and its contributors :)
Regards,
- Paul
- Paul
On Tue, Jul 25, 2017 at 11:38 AM, Julian Foad <julianfoad_at_apache.org> wrote:
> 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 19:01:27 CEST