Re: svn delete removes read-only files

On 16.11.2013 00:57, Rick Varney wrote:
> Branko Čibej <brane <at> wandisco.com> writes:
>
>>
>> You're allowed to modify and commit changes to a file that has the
>> svn:needs-lock property regardless of whether it's locked or not.
>> svn:needs-lock is not a constraint, it's just a reminder.
> I see. I was thinking of it as a constraint, because we had customized our
> setup to prevent checking in unlocked files in our pre-commit hook script.

Sure, you can use a pre-commit hook to prevent committing files without
locks; but there's nothing you can do to prevent anyone from editing it,
short of using advanced access control in the working copy directories
and modifying or otherwise wrapping the Subversion command-line client.

> Maybe this behavior can be made optional, enabled via the
> configuration file?

Changing client behaviour via config file options is almost always a bad
idea ... every such option makes testing more complex and bug triage
more time consuming.

I'm not saying that there's no chance we'd ever change the way 'svn
delete' behaves; I only stated some of the arguments against that, and
there can certainly be other opinions. But we'd have to see some
indication that the case you describe is actually moderately common.
Frankly, I doubt it is; because mandatory locking isn't, in my
experience, a very common workflow with Subversion.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com