As I’ve probably said before I’m not a fan of working on Windows, but sometimes the choice isn’t yours to be made. Couple this with the problems you have with SVN, where pieces of software like WordPress, which will often obliterate your metadata directories during updates, things can quickly turn sour. Recently I had to upgrade TortoiseSVN to 1.7, which thankfully fixes this problem. This is a decent improvement because it essentially gets rid of all those annoying .svn folders we’ve come to know and hate. But, there was a little work to be able to use it. It’s not too complicated, but this should be handy to people with the same problem.

Note: You may want to read through this post before doing anything to make sure you don’t cause yourself any extra problems

Also note: I highly recommend committing any changes and updating before starting, and also doing an SVN cleanup of the whole folder.

First of all you will get the new version of TortoiseSVN installed. You will notice the SVN icon overlays on your directories will disappear, and when you right click the SVN options have pretty much gone, leaving you the option to SVN Upgrade working copy. Selecting this then gives you the option to Upgrade to the new 1.7 format. If you’re lucky this will just work and you’re set. If like me you see errors like this:

Subversion reported an error:
Can't open directory
'C:\path\to\blog\wp-includes\js\tinymce\plugins\safari\.svn\text-base':
The system cannot find the path specified

then you need to do a little more work. I found that going ahead and creating those text-base folders is fine. You may get other files or folders that need creating too, for instance I found I had to create a few entries files too.

Other updates may have got rid of the .svn folder altogether, giving you an error message like:

"C:\some\folder\" containing working copy admin area is missing.

If you see this the best thing I found was to copy that directory out to back it up, then delete it. Once you finish upgrading TortoiseSVN you can copy it back in. Careful not to forget where these go – it’s easy if you have several! I found myself making folder structures on the desktop that mimicked the one I was copying the directory from, so I could just drag it back in and let Windows work it’s merging magic for me.

Now, at this point you need to remember that upgrading TortoiseSVN will get rid of your ability to run things like SVN update and SVN cleanup on your working copies. I recommend running an SVN cleanup after fixing errors like the ones above and you may even find that you’ll need others too. Luckily for me I had a command line version called SlikSVN installed too. With the <=1.6.x version of SlikSVN (I would recommend 1.6.9 – 64bit available too!) you can still make changes to your working copy even though the GUI based TortoiseSVN won’t let you. You can check what SlikSVN older versions are available for you to download.

Finally, when you’ve sorted the errors and run another SVN cleanup you can upgrade to 1.7. Don’t forget to copy (or merge) your folders back in. They should just show up with the red (modified) icon once copied back in, leaving you to commit them.

Don’t forget to update SlikSVN once you have finished everything, as once you’ve upgraded your repositories you will no longer be able to work on them from the command line.

Tagged with:

### 5 Responses to TortoiseSVN: When “Upgrade the working copy to the new 1.7 format” doesn’t work

1. Brian says:

All well and good, but what if you have 555(!) of those little .svn beggars, none of which has a text-base folder in it? This is programming stupidity!

• Leonard says:

I feel your frustration! ;) At this point I would write a batch script to go through and create them for me to be honest. I would even be tempted to install Perl, PHP or even just cygwin for Linux shell commands, so I didn’t have to do it with batch scripts.

• Brian says:

Actually, all of those .svn directories are doing version control in my Perl development environment…so yeah, I swotted up a Perl script to recurse through all of them and make text-base folders just to keep svn happy. Worked like a charm, but I still vehemently maintain that the svn upgrade should have worked right out of the box. If I programmed like that, I wouldn’t have any customers. Bah! (of course, my remarks don’t take into consideration the large body of folks who make their living by constantly babysitting svn; for them, this is just job security)

• Mikkel says:

Not that I’m an svn fanboy or anything, but why do you think this is a problem with svn? It sure sounds like the problem is with WordPress, or rather the way you keep it versioned and updated. If you didn’t mess around with the .svn folders, upgrades work perfectly. At least I haven’t had a single problem with the svn 1.6->1.7 upgrade, other than having to upgrade every single checkout (I came here from an “svn upgrade recursive” search).

If you’re going to use a version control system, you owe it to yourself to put some time into reading about how you’re supposed to use it. For svn, the online svnbook is good reading. You should never (need to) manually create text-base folders. They should be created by svn checkout/update/add.

• Leonard says:

You’re right. Following the SVN documentation properly would mean you wouldn’t end up deleting these folders. I should show less hate to SVN itself, although the fact they’ve changed it to not work like this anymore would suggest it wasn’t a great way of doing things, especially in this age of CMSs and off-the-shelf software.

Alas, I’ve modified it to reflect the hatred towards a more fitting opponent ;) There is probably a plugin or something that made SVN <1.7 and WordPress work nicely to be fair, too. Thanks for the feedback.