Dangling locks in the Subversion tree

September 26, 2008 by
Filed under: Configuration Management 

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.

Comments

2 Comments on Dangling locks in the Subversion tree

  1. Stefan on Sat, 27th Sep 2008 10:09
  2. This really is a problem, but only if you don’t have the command line client installed. You could break this lock easily:

    svn unlock –force url/to/file

    I’ve changed TSVN so that the repository browser will show the ‘break lock’ context menu entry for non-HEAD revisions now. So in TSVN 1.6, you could resolve this by:

    1. open repository browser for folder where the renamed file is
    2. click on the ‘HEAD’ button on the top right, enter the revision where the lock still exists (e.g. HEAD revision – 1, or use the log dialog to find the last revision where the file had the original name).
    3. right-click on that file, choose “break lock”
    4. that’s it

  3. Oskar Andreasson on Sat, 27th Sep 2008 10:53
  4. Thanks stefan, I never tried that one (I did try svn unlock –force path/to/local/file but got an error from that solution). Very good to know how to solve this without messing with IT dept as I’m sure it will happen again:-).

Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!