I always try to stay on top of the latest fixes/features of the apps that I use regularly but (like most programmers) I can be pretty lazy. Lucky for me, there’s a really simple way to do this with Subversion. In fact, this is typically the way that anyone developing for WordPress will have their system set up. I’m going to assume that you are relatively familiar with the normal WordPress installation process and that you have Subversion installed on your webserver (sorry to those on shared hosting, you probably won’t have access to Subversion). The Subversion book is a great resource if you’re not too familiar with svn.
Those not too familiar with the inner workings of WordPress or other opensource software might be surprised to know that the WP code repository is open for anonymous browsing. People need easy access to the code so they can contribute to the project. This means that anyone can use the Subversion client to create a working copy of any WordPress branch.
We’re going to use the command-line svn client to create a working copy from one of the tags in the WordPress Subversion repo. First, let’s take a look at what’s there. Run svn list http://svn.automattic.com/wordpress/ and you’ll see a list like the following:
branches/
tags/
trunk/
This is a typical Subversion repository layout. Most of the work happens in trunk. When a milestone is reached, that revision of the trunk is copied into the tags/ directory and given the corresponding version number as a name. Depending on the type of release, we may see that revision copied into the branches directory as well. This is used for bug fixing of the specific versions while new work can start happening in the trunk.
If you want to stay on the cutting edge of development (or bleeding, even) and don’t mind the occasional hiccup on your blog, you can check out the trunk. To play it safe, you should check out one of the tags. svn list http://svn.automattic.com/wordpress/tags, will show you the following:
1.5/
1.5.1/
1.5.2/
2.0/
…
2.6.3/
2.6.5/
2.7/
Let’s grab 2.7, since it is currently the latest release. In your webroot enter svn checkout http://svn.automattic.com/wordpress/tags/2.7 <directory> where directory is something like “blog” (or “.” if you want to serve the blog directly from the root of your site). Subversion will grab all the WordPress code and create a working copy of it in this directory. At this point you can continue with the normal WordPress installation instructions, after the point where you would have unpacked the archive you downloaded from wordpress.org.
Once you’ve got WordPress running the fun begins. Say a few weeks go by and a critical bug fix is released as version 2.7.1. All you need to do is go into the root of your working copy and run svn switch http://svn.automattic.com/wordpress/tags/2.7.1 and you’re done. Subversion will update your installation as necessary. You’ll need to do your database upgrades regularly obviously, and note also that if there have been any changes to the wp-config-sample.php that you’ll need to make those changes in your wp-config.php manually.
If you change your mind and decide to try something a bit more adventurous, you can run the same switch but point it to the /trunk directory rather than /tags/2.7.1, and then simply svn update periodically to get the very latest code. This makes upgrades a snap, and your local changes will be preserved throughout any switches or updates.
Keep in mind that none of this is specific to WordPress or Subversion. This concept is applicable to pretty much any web app that uses some sort of version control. I use this for PHPMyAdmin and Mantis too.
One last thing that I highly recommend is that you configure your webserver to deny requests trying to read from the .svn directory where Subversion stores your working copy metadata. This becomes very important if you also use this technique with proprietary projects where doing so could reveal sensitive information. To do this in Apache2 add the following block to your httpd.conf or apache2.conf file:
<DirectoryMatch “^/.*/\.svn/”>
Order deny,allow
Deny from all
</DirectoryMatch>
