Subversion is a wonderful tool. Even on projects where I’m the only person creating code, it’s great to be able to go back to any version at any time, have an easy way to synchronize both my desktop and notebook machines to the same code base, know that I always have an off-site backup, and, of course, be able to deploy with Capistrano, which pulls code from the repository.

But Subversion can also be confusing and frustrating. On Windows, the TortoiseSVN client, which integrates into Windows as a shell extension, makes it pretty painless, as long as everything is working. And both Aptana and NetBeans have built-in Subversion clients.

Subversion Frustrations

But every now and then, I find my projects in a state in which I just can’t get files to check into the repository. A couple days ago I had a project that hung the Subversion client whenever I tried to commit the new files. It happened again the next day with a fresh set of files and a new project in the repository. I’m not sure what went wrong here, but I seem to be having a little more trouble than usual after moving projects from Aptana to NetBeans.

There’s one way in which I know I have messed up on more than one occasion. When I’m creating a new project and adding in files from other projects, I sometimes get sloppy and move a folder using Windows, or the IDE’s file manager, which brings along the .svn files from the “alien” project, which makes Subversion quite unhappy. I had thought, at first, that the IDE’s with built-in Subversion support would take care of the doing the right thing if you used their file browser to move a folder, but they don’t—they happily move the .svn files and leave your working copy in an unacceptable state.

Emergency Treatment for Windows SVN Files

When all else fails, I’ve found this little bit of Windows shell code to be a savior:

for /r YOURPATH %f in (.svn) do rd /s /q "%f" 

Enter this in a Windows shell, substituting the top-most folder you want to affect for YOURPATH, and it will strip every vestige of Subversion from your files (or replace YOURPATH with a period (.) and it will operate on the current folder and all those below it). If you do this with an entire project, you can start fresh and import it as a new project if you want, though you lose all the change history up to that point. You can also apply this to a single folder if you inadvertently added .svn files that relate to another repository, as when moving a folder from another project. Once you strip all the .svn files, you can add the new files to the project.

Credits: I got this bit of shell code from Wyatt Preul’s Blog, where he discusses using PowerShell as well as the regular shell. Note that he does not put the final %f parameter in quotes, which will cause the command to fail if there are any directories that have spaces in their names.

Keeping Subversion Happy

I’d appreciate any tips anyone can add about how to keep Subversion happy, and how to troubleshoot it when commit attempts just hang.

It turns out that my article on using SSH keys to speed login isn’t quite complete, assuming you’re using Subversion. You need to take one more step to enable Subversion (SVN) to use the private key generated by PuTTYgen: adding a line to Subversion’s configuration file.

(Note: I’ve now updated that article to include this item.)

Subversion’s configuration file is located in the Application Data directory under your user account. The full path is:

C:\Documents and Settings\{your windows user name}\Application Data\Subversion\config

Note that Application Data is a hidden folder, so to locate this file you must have Windows set to show hidden files and folders.

Open the config file in any plain text editor (such as Notepad) and add the following line:

ssh = $SVN_SSH plink.exe

plink.exe is the command-line link setup program that is included with PuTTY.

You’ll also need to make sure that the PuTTY directory is listed in your system’s Path.