However, if you recently tried to upgrade to the latest version using the instructions at the WordPress Codex, you likely ran into a problem with an error mesage like this:

$ svn sw http://core.svn.wordpress.org/tags/2.8/ .
svn: 'http://core.svn.wordpress.org/tags/2.8/'
is not the same repository as
'http://svn.automattic.com'

This is because sometime between the release of 2.7.1 and 2.8, the URL of the WordPress SVN repository changed from http://svn.automattic.com/wordpress/ to http://core.svn.wordpress.org/.

The fix

To properly update WordPress after this change in the SVN repository location, we need to first run the svn sw –relocate command to relocate or point the checkout to the new repository URL:

svn sw --relocate http://svn.automattic.com/wordpress/tags/2.7.1/ http://core.svn.wordpress.org/tags/2.7.1/ .

Note that we are just changing the checkout’s repository from the old one to the new one – we aren’t yet pointing to the new version. (Note – this assumes you are currently running version 2.7.1)

After this, we can now we can switch to the new version.

svn sw http://core.svn.wordpress.org/tags/2.8/ .

Additionally, it’s worthwhile to run an svn up after this, just to make sure externals (like Akismet) are properly updated as well.

Note that this overall process has two steps – first pointing the checkout to the new repository URL, without switching to the new version, and then switching to the new version. I am not sure if you have to do it in two steps like this, but I can confirm this worked for me, and judging by the instructions in the SVN documentation, this is likely the correct way.

Thankfully, following the well-written guide on the WordPress.org Codex was easy and straightforward – both for changing this existing installation over to SVN and for setting up a new blog for RunTrackr. I now look forward to updates, just so I can relish in the ease of upgrading.

SVN is a powerful tool (I use it both at work and for personal projects) and is a great SCM tool for small-to-medium sized projects. The command-line tool is easy to use, and for Windows, the great TortoiseSVN tool can’t be beat. (It integrates nicely with the Windows explorer and is compatible with the Eclipse Subclipse SVN integration plugin) Additionally, the integrated Apache HTTP server lends itself nicely to many web-based applications that not only enable browsing but also form the basis for some remote backup/file-sharing/synchronizing services out there.

One thing you’ll probably want to do after switching WordPress (or any web application) to a SVN checkout is to protect the .svn metadata folders from public access. These folders are used by the Subversion client to keep track of changes and determine what files need to be updated when getting the latest versions. They also contain information about what SVN server you are using – in some cases you don’t want to reveal these details, and in any case it’s always best practice to deny access to anything except for that which you explicitly want to make public.

Doing this is fairly straightforward with Apache. All you need to do is edit your .htaccess file in the root of your web directory. Add an entry like this:

# SVN metadata folder protection.
<IfModule mod_rewrite.c>
  RewriteRule ^(.*/)?\.svn/ - [F,L]
</IfModule>

This works for me, though some have used other regular expressions to accomplish the same task.