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
