subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@wandisco.com>
Subject Re: svn delete removes read-only files
Date Thu, 14 Nov 2013 20:21:03 GMT
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@wandisco.com

Mime
View raw message