[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: Thu, 14 Nov 2013 21:21:03 +0100

On 14.11.2013 19:24, Rick Varney wrote:
> Hello,
>
> At my company we are using the lock-modify-unlock model, with the
> svn:needs-lock property set on most files. We have a pre-commit hook
> that prevents committing unlocked files. We are currently on
> Subversion 1.6.6.
>
> Here is a typical frustrating sequence that happens when removing files:
>
> # User deletes file, forgetting to get the lock first.
> $ svn rm foo.txt
> D foo.txt
>
> # User tries to commit.
> $ svn ci -m "deleted foo.txt"
> Deleting foo.txt
> svn: Commit failed (details follow):
> svn: Commit blocked by pre-commit hook (exit code 1) with output:
> ...
>
> # Argh! User tries to lock the deleted file, so commit can proceed.
> svn lock foo.txt
> svn: Can't change perms of file '/home/varney/foo.txt': No such file
> or directory
>
> # Curses! Foiled again!
> # Actually, the user did get the lock, but doesn't realize it, because
> svn gave an error message.

Good catch; this is the actual bug. It's OK to lock a nonexistent path,
and if the lock had been acquired on the file's URL instead of the
working copy path, it would most likely work without emitting an error.

> # At this point the user contacts me for help.
>
> While I understand why svn behaves this way, it *is* counter-intuitive.
>
> Here is my suggestion for a change to how svn delete behaves, to avoid
> this situation:
>
> Modify svn delete so it refuses to remove read-only files. This way,
> the need to lock becomes more intuitive to users, in the same way
> locking a file opens up write permissions so a file can be edited.
>
> What do you think? Any alternatives I have not considered? Should I
> open a feature request for this?

I disagree with the behaviour change because it makes 'svn delete' in
the presence of svn:needs-lock behave exactly opposite to every other
command. IMO, it's quite enough to simply fix the bug where we try to
change the permissions on a non-existent local path.

So I suggest you file a bug for that, not for the behaviour change.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-11-14 21:21:39 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.