As is usual, it took me quite some time to listen to Alex’s repeated suggestions to use SVN to maintain my installation of Wordpress (the software this journal runs on). It was actually Alex’s excellent Twitter Tools plug-in that provided the final incentive for my upgrade to Wordpress 2.1, and I took advantage of the situation to transition to set it up to use SVN for updates.

The official Wordpress page on SVN access provides very little information about how to actually use SVN to manage your installation. I recommend reading the more detailed page on the Wordpress site, and both pages of Seth Kinast’s entry on the subject.

For some reason, all of the available online literature about the subject recommends checking out the trunk or tagged versions of Wordpress. I spoke with Alex today, and he recommended using the branch versions instead, which makes more sense to me, as well. Using branch versions ensures that you will still get security updates attached to a particular release upon updates. If you check out the trunk version, you will be using potentially broken developer builds of Wordpress.

The svn command you would use to check out the version 2.1 branch is:

cd journaldirectory svn co http://svn.automattic.com/wordpress/branches/2.1/ .

My Wordpress installation is “stock” except for the PHP files that implement RSS and Atom feeds, which have been modified to prevent private entries from being revealed. An svn up will not overwrite modified local files, so I can update away on a given branch without worrying that those files will be overwritten. Because I travel so often, I will likely end up doing regular updates via a cron job. At this point, most people point out that an update will break your site if you have modified the core files; luckily for me, it is unlikely that the feed templates will change at all during the lifecycle of a given branch.

If you are afraid you might break your site (I was!), I recommend making a copy of your database and working from a staging directory on your site. Unfortunately, successful duplication of a Wordpress installation (to a different directory) requires manual editing of the database copy, which doesn’t seem right…