Skip to content

Tracking WordPress in a Subversion vendor branch

Two months prior to writing a script to upgrade MediaWiki installations using Subversion vendor branches, I wrote something similar for WordPress. It’s a little bit more limited and should really incorporate some of the improvements made for the MediaWiki version, but it worked fine so far:

cat upgrade-wordpress.sh 
#!/bin/bash
 
svn_repo_url=file:///var/svn/blog.omega-research.org/vendor/wordpress/
last_version=$1
new_version=$2
 
tmp_dir=`mktemp -d`
cd $tmp_dir
 
for version in $*; do
    echo "Downloading and extracting WordPress version $version..."
 
    if [ -z `svn ls $svn_repo_url|grep $version` ]; then
        branch=`echo $version |sed -e 's/\.[0-9]\+$//'`
        archive_file="wordpress-$version.tar.gz"
        md5_file="wordpress-$version.md5"
 
        wget "http://wordpress.org/$md5_file"
        wget "http://wordpress.org/$archive_file"
 
        if [ `md5sum $archive_file |cut -f 1 -d ' '` != `cat $md5_file` ]; then
            echo "MD5 sum did not match!" >&2
            exit 1
        fi
 
        tar --extract --ungzip --transform "s/^wordpress/$version/" --file $archive_file
        svn_load_dirs.pl $svn_repo_url -t $version current $version
    fi
done
 
cd -
svn merge "$svn_repo_url$last_version" "$svn_repo_url$new_version" .

I’m actually planning to make both scripts a little bit more generic (in the sense that svn_repo_url becomes an external param) and to track future changes to them using GitHub’s Gist. (How ironic is that, tracking an script for Subversion using Git?)


    6 Comments ( Add comment / trackback )

    1. (permalink)
      Comment by maz
      On September 21, 2009 at 15:48

      I use Capistrano and Piston to track WordPress upgrades. Some of the articles on your site were useful in figuring out how to keep the custom files separate.

      First I imported the latest version using Piston:

      piston import --repository-type svn http://svn.automattic.com/wordpress/tags/2.8.4 wordpress-current 

      Then I added this deployment recipe to deploy.rb:

      namespace :wordpress do
        desc 'Updates to latest tagged version from Wordpress repository.'
        task :update do
          base_repos, current = `svn pg piston:root wordpress-current`.split(%r{/(?=[^/]+/?$)}).map {|v| v.strip}
          latest = `svn ls #{base_repos}`.split(%r{/\s*}).sort_by {|v| v.split(/(\d+)/).map { |v| v =~ /\d/ ? v.to_i : v }}.last
          logger.trace("Current WordPress version: #{current}")
          logger.trace("Latest WordPress version:  #{latest}")
          if current == latest
            logger.trace("No update necessary")
          else
            # Update with piston
            if RUBY_PLATFORM =~ /mswin32/
              result = %x(call piston switch #{base_repos}/#{latest} wordpress-current)
            else
              result = %x(piston switch #{base_repos}/#{latest} wordpress-current)
            end
            #TODO: what do I do here? Must check when a new version is available :)
            logger.trace(result)
          end
        end
      end

      You can then update to the latest WP version with:

      cap wordpress:update
      e

      Note that if you are comfortable using the WordPress trunk (which I would not recommend for a production environment), then you can set Piston to use the trunk directly and then just use

      piston update
      — no need then for a Capistrano recipe.

      This may need some tweaking depeding on your installation. Also, the latest version of Piston does not support the “switch” command. This is an omission, so you would have to go back to an earlier version until it is reinstated. And the extraction patterns might need some tweaking as Piston evolves, but you get the idea.

    2. (permalink)
      Comment by halfgaar
      On January 18, 2010 at 14:01

      @bigsmoke
      You’ve been publishing so much about version control of webapps; perhaps it’s an idea to comment on the relevancy of some of your own posts, because I don’t know what is true anymore…

    3. (permalink)
      Comment by Rowan Rodrik
      On January 19, 2010 at 12:25

      So true. I should also turn on comment threading somehow. That’s supported in newer WordPress versions, but not in my theme yet.

    4. (permalink)
      Comment by halfgaar
      On January 19, 2010 at 20:40

      Comment threading? No!!!!! Go to http://www.tweakers.net and see why that doesn’t work.

      Are you being ironic here or have you forgotten the no-threading revolution?

    5. (permalink)
      Comment by Rowan Rodrik
      On November 3, 2010 at 13:21

      I was just googling around on this subject a bit and noticed that it might be a serviceable idea to clean this script up a bit and make a proper release of it (instead of turning it into a Gist, for example). If anyone is interested, let me know. Your plea might just provide the missing motivation.

    6. (permalink)
      Comment by Rowan Rodrik
      On November 3, 2010 at 13:24

      Halfgaar,

      For WordPress it goes that there’s more than one way not to make a mess of it. There’s this way, and there’s that way.