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. br...@wandisco.com
