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
