[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn delete removes read-only files

From: Branko Čibej <brane_at_wandisco.com>
Date: Sat, 16 Nov 2013 03:00:37 +0100

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
Received on 2013-11-16 03:01:12 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.