Paul Hammant wrote:> It will help the owners of subversion repos
preventing files from being> overwritten that they do not want to be
> It will help subversion end-users not upset the owners of repositories
> by changing files (and committing them back) that there are not
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:
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
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:
That's all fine -- users can and should do whatever they want or need to
with their local files.
Received on 2017-07-21 11:40:29 CEST