svn delete removes read-only files
From: Rick Varney <rick.varney_at_sbcglobal.net>
Date: Thu, 14 Nov 2013 10:24:03 -0800 (PST)
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.
# 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?
Best regards,
Rick Varney
|
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.