Using Subversion with WordPress – Part 2: Maintaining Vendor Branches and Upgrading WP Core Files

This article assumes you have already read, “Using Subversion with WordPress – Part 1: Creating Vendor Branches and Integrating your Existing Code“. In short, you want to use Subversion to track/maintain local versions of both WordPress code and your own internal project code, side-by-side, all in the same svn repository.

In the previously mentioned article we used WordPress version 2.3.1 as our initial vendor drop. The following procedure illustrates how to use svn merge to quickly upgrade WordPress core files from version 2.3.1 to version 2.3.2 – without losing your local changes – but could be used as a general outline for upgrading any version of WordPress provided you followed the steps discussed in Part 1. Note: Backup your files and database before attempting any of this. Also, although not strictly required, the following steps assume you have some kind of shell access (like ssh) and a command line subversion client (like svn).

Maintaining Vendor Branches -
To perform this upgrade, we check out a copy of our current vendor branch (which contains our WP 2.3.1 source code), and replace that code with the new WP 2.3.2 source code. So, we simply copy the new files on top of existing files and directories. The goal here is to make our current directory contain only the new WP 2.3.2 code, and to ensure that all that code is under version control. I use the svn export command to grab the WP 2.3.2 source code – but downloading and extracting the WP files manually works just as well.

1. Prepare Current and New Code

$ mkdir upgrade
$ cd upgrade
$ svn co http://svn.yourdomain.com/vendor/wordpress/current/
$ svn export http://svn.automattic.com/wordpress/tags/2.3.2/
…

2. Copy, Resolve Conflicts, and Commit Changes

$ cd current [optionally, delete all files but NOT folders / dont delete .svn folders]
$ cp -a ../2.3.2/* .
$ svn status
$ svn ci -m "commiting WP 2.3.2 vendor drop to current branch"
$ cd ../../
$ rm -rf upgrade
…

3. Tag the New Version
Our current branch now contains the new vendor drop. We tag the new version (in the same way we previously tagged the version 2.3.1 vendor drop – in Part 1)

$ svn copy http://svn.yourdomain.com/vendor/wordpress/current \
http://svn.yourdomain.com/vendor/wordpress/2.3.2 \
-m "tagging WordPress 2.3.2"
…

4. Merge the Differences and Commit Changes
Checkout a copy of your current project (from Part 1 – we used the folder: “newproject”). Merge the differences between the tag of the previous version (WP 2.3.1) and the new current version into our main development branch. Type svn status to see what files were modified and resolve any conflicts. Run svn add and svn delete commands where appropriate. Commit the changes and our local version of WP will now been completely upgraded without over-writing or deleting any existing modifications we may have previously made.

$ mkdir newproject
$ cd newproject
$ svn co http://svn.yourdomain.com/branches/newproject .
$ svn merge http://svn.yourdomain.com/vendor/wordpress/2.3.1 \
http://svn.yourdomain.com/vendor/wordpress/current .
$ svn status
$ svn ci -m 'merging WordPress 2.3.2 into the main branch'
…

That’s all there is to it!

And, best of all, every change made to your internal project code – including those made to WP core files – is now documented and tracked from within your own local version control system.

Note: Don’t forget to visit http://www.yourdomain.com/wp-admin/upgrade.php in your web browser once you’ve completed all of these steps to make sure any database upgrades get applied as well.

Comments 11

  1. mike wrote:

    what about all your custom plugins, themes, etc? those will be overwritten with these commands…

    Posted 19 Apr 2008 at 5:24 pm
  2. elran wrote:

    no they won’t.

    if you followed steps #5 and #6 from Part 1 and prepared your files correctly – all your custom plugins and themes should already be under version control at this point.

    furthermore, you would be merging only the differences between 2 versions of WordPress (an upgrade of core files) – this has nothing to do with your custom plugins and themes.

    Posted 20 Apr 2008 at 1:09 pm
  3. tunesmith wrote:

    It would be nicer to just pull over the wordpress update through a svn update, and then merge it into one’s own workspace. Is this possible? It just seems that that export/delete/copy process is something that subversion should be able to do.

    The alternative is externals, but it requires wordpress being in its own directory, and wp-content screws that up.

    Posted 06 Nov 2009 at 9:28 pm
  4. gib wrote:

    fully agree with tunesmith,
    what about a svn switch automattic/tags/2.9.1.1
    inside vendor/wordpress/current ?
    anyway very useful articles, thanks a lot !

    Posted 08 Feb 2010 at 2:34 am
  5. Spencer Hill wrote:

    Hey man – looks like a great tutorial to hit the need right on the head, but you lost me in part two where you said: “cd current…” where did we create a folder called current?

    Posted 26 Apr 2010 at 2:55 am
  6. elran wrote:

    Hi Spencer,

    we created the “current” folder automatically when we checked out a copy of the current vendor branch.

    $ svn co http://svn.yourdomain.com/vendor/wordpress/current/

    this creates the folder for you.
    see “Part 1” for more details.

    Posted 27 Apr 2010 at 11:57 am
  7. ben wrote:

    Nice article, but…in step 2 has some questions.

    How about wordpress original source delete some files or directories?

    Use cp -a, you will leave the deleted files or directories in your repositories, and never aware about their deletion.

    Any good idea?

    Posted 07 Jan 2011 at 9:52 am
  8. patrick wrote:

    ben,

    old files may indeed be left behind, but you can get the full discussion from the relevant section of the subversion book to which the author refers in the first article (part 1). That section is comprehensive and also provides links to some tools to deal with such problems. Alternatively, if you just want to know that they are no longer part of the repos, you can do an svn diff –summarize between your working copy and a current vendor export.

    Posted 14 Apr 2011 at 7:41 pm
  9. corporate gifts wrote:

    Hi, every time i used to check webpage posts here in the early hours in the daylight, since
    i enjoy to find out more and more.

    Posted 22 Aug 2014 at 11:59 pm
  10. http://www. wrote:

    A good pair of custom socks can be worn at a formal gathering or while
    taking in a ball game. If you are looking for a corporate gift idea to customize, look
    online. You can get all sorts of gifts like coffee mug, pen,
    pen stand, mobile stand, wall clock and many other things.

    Posted 27 Sep 2014 at 10:53 pm
  11. ig wrote:

    Excellent beat ! I would like to apprentice
    while you amend your site, how can i subscribe for a blog
    website? The account aided me a acceptable deal.
    I had been tiny bit acquainted of this your broadcast offered bright clear idea

    Posted 25 Feb 2017 at 12:15 pm

Post a Comment

Your email is never published nor shared. Required fields are marked *