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>. 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.
> Sure, it's only read-only bit and can be flipped by anyone who can
> launch WindowsExplorer and pop a properties tab for the file, etc.
> That's worth mentioning because the time honored provision of corporate
> files over a network share comes with an ability to lock the read-only
> bit for files. That said the end user could copy those files to their C:
> drive.
That's all fine -- users can and should do whatever they want or need to
with their local files.
- Julian
Received on 2017-07-21 11:40:29 CEST