Dangling locks in the Subversion tree

I recently ran into another rather peculiar and interesting case with subversion. As I've already explained, I don't have actual physical access to the subversion servers we are perusing for our project. We use TortoiseSVN for access to the repository on our local systems.

My boss was working with some excel and word files checked into the repository. He had template.xls locked as he was working in it, he decided to rename it to a template, so template.xlt it is (and checked in). After doing some more work, he decided this was a bad idea, so he changes it back to template.xls, and tries to check it back in again... no luck, it wont work.

15-20 minutes worth of investigation later, we found the problem. TortoiseSVN had been configured to always check "Keep Locks" on commit, hence the client kept the lock when he commited the template.xls deletion. To fix this problem, run svnadmin lslock and then svnadmin rmlock the file in question. Please note that this requires actual access to the physical subversion repository. Http or svnserve will not do in other words.

A step by step on how to cause the Dangling lock problem -- All of the actions are done via TortoiseSVN interface:

1. Create a repository.
2. Check out the repository.
3. Add a file to the repository, set the svn:needs-lock property.
4. Commit the file.
5. Lock the file.
6. Change name of the file, and check the "Keep locks" checkbutton.
7. Commit the changes.
8. Change the filename back to the original filename.
9. Commit the change. This step will fail.

This is a rather funny problem imho :-). We finally managed to get it fixed after contacting the IT department and sending them the command. 10 minutes to cause the problem, 20 minutes to analyze it, 20 hours to wait for the fix. Sometimes there should be less depth in organizations.