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.

Scenario:
Let’s say you have an in-house web developement project that is built upon or otherwise dependent on the WordPress core files. This can be for something as simple as creating/customizing your own WP themes and plugins, or as complex as maintaining your own modified versions of WP core files, with additional components/modules, etc. The important thing is that you imagine a scenario where you are already using Subversion to commit changes/updates to this internal project of yours. However, a problem occurs whenever a new version of WordPress is released. You need to upgrade the WP core files whithout losing any of the custom modifications you’ve been making up until now. Ideally, you would like to apply (to your internal project) only the changes made to the upgraded WP core files without over-writing any of your own work.

Solution:

“The solution to this problem is to use vendor branches. A vendor branch is a directory tree in your own version control system that contains information provided by a third-party entity, or vendor. Each version of the vendor’s data that you decide to absorb into your project is called a vendor drop.” (quote)

So, in this case, the third-party entity or vendor, is WordPress. What we want to do is: absorb the WP code into our own project. The rest of this article is going to illustrate the concept of “vendor drops” as they would apply to this particular scenario and using WordPress as the third-party vendor. Some of the benefits of this method are described in the article that the previously mentioned quote came from. In addition, this article goes on to describe the exact same process (but in more general terms) in a section entitled: General Vendor Branch Management Procedure. Well, here is my “Specific Vendor Branch Management Procedure” for WordPress.

Vendor Branch Management – Description

“Managing vendor branches generally works like this. You create a top-level directory (such as /vendor) to hold the vendor branches. Then you import the third party code into a subdirectory of that top-level directory. You then copy that subdirectory into your main development branch (for example, /trunk) at the appropriate location. You always make your local changes in the main development branch. With each new release of the code you are tracking you bring it into the vendor branch and merge the changes into /trunk, resolving whatever conflicts occur between your local changes and the upstream changes.” (quote)

Our Setup -
Let’s use WordPress 2.3.1 as an example. A newer version of WP (2.3.2) was just released and we’ll be using that version in a follow-up article to show how you can maintain this setup across multiple WP version upgrades without losing your local changes. However, for right now, we’ll assume that this is your first vendor drop and that your current project is already using Subversion and is also built against WP 2.3.1. In theory, you could use this same procedure with any version of WP – just make sure to start with an initial vendor drop that is the exact same version of WP as the one your project is currently using. Remember, we are not upgrading WP yet. We are just importing the WP code into our existing subversion-based system, side-by-side with our internal project. 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).

Creating Vendor Branches -

1. Download Vendor Source Code

$ mkdir workspace
$ cd workspace
$ svn export http://svn.automattic.com/wordpress/tags/2.3.1/
…


2. Importing Initial Vendor Drop

$ cd 2.3.1
$ svn import . http://svn.yourdomain.com/vendor/wordpress/current \
-m "importing initial WordPress vendor drop"
$ cd ../
$ rm -rf 2.3.1
…


3. Tagging Initial Vendor Drop

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


4. Copying Vendor Drop into a New Branch

$ svn copy http://svn.yourdomain.com/vendor/wordpress/2.3.1 \
http://svn.yourdomain.com/branches/newproject \
-m "bringing WordPress 2.3.1 into the new branch"
…


5. Check Out and Add Customizations
We check out our project’s new branch – which now includes a copy of our first WP vendor drop – and we begin customizing or re-applying any changes to the code. Unless you’re starting from scratch, this probably just involves copying over any files and folders that were previously a part of your internal project code. Since we made sure to import the exact same version of WP that was used in our in-house development (this is not an upgrade) – there should be no conflicts and fewer surprises.

$ mkdir newproject
$ cd newproject
$ svn co http://svn.yourdomain.com/branches/newproject .
$ cp -a /path/to/your/oldproject/* .
…


6. Resolve conflicts and Commit Changes
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 modified version of WP is now completely integrated into our in-house project.

$ svn ci -m "commiting changes into the new branch"
$ cd ../
$ rm -rf newproject
…


That’s It! You’re Done.

At this point you might be thinking to yourself: “Well, that’s not exactly a time saver.. now is it?” And, you’d be right! But we won’t stop there! With WordPress integrated into our in-house versioning system – we can now use svn merge to quickly perform WP upgrades on our internal project code without risk of ever deleting or over-writing our own work.

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

[ Be sure to check back for the follow-up article entitled: "Using Subversion with WordPress - Part 2: Maintaining Vendor Branches and Upgrading WP Core Files" ]

This site was in maintenance mode for a good part of the evening due to an incompatibility with WP 2.3.1 and the previous theme used here on Techblog. I spent some time trying to work out the problems but the breakage was pretty severe so i figured it was time to either design something new from scratch, or just grab one of the many readily available WP themes and use that for a while. I decided to go for the latter choice.. i might still spend some time adding more customizations, but for now i needed something that worked well and looked clean.

Anyway, after trying out a bunch of themes from the WP Theme Viewer and playing around with the WP Theme Generator, i was able to narrow my choices down to about 5 themes and finally went with the blog.txt theme by Scott.

I’ve already made some SEO related modifications to the header.php template file. Also, i had to upgrade my tags structure – twice! Once from some really old wordpress tagging plugin that kept your tags in a key called: ttaglist, in the postmeta table. I had to use the UTW plugin to import these old tags. Then came the second upgrade. I used the new built-in tag import feature in WP 2.3.1 to convert my newly created UTW tags into the native WP tagging structure. Everything seemed to go smoothly, and i was able to get rid of all my old tagging plugins and install Simple Tags for advance tag management. I had to get rid of a few other really old plugins, but the site runs much faster now, and i’m sure it won’t take me too long to find a ton of new plugins to clutter up my site in no time!

So far, i have to say, i’m pretty happy with the upgrades. I haven’t tested everything too thoroughly yet, so more changes might still be on the horizon.. including another complete theme change. Just giving you all heads up!

According to Microsoft, Windows 2000 SP4 has moved from “mainstream to extended support”. More info on the difference between these two can be found at the Microsoft Lifecycle site. What this basically means for Windows 2000 users is: no more new features, and mostly eveything other than security updates, will now cost money. While this might be alright for some people, when i think of what a mess Microsoft has made of maintaining previous versions of their OS, like Windows 98, and now the problems they’re having with the recent Windows 2000 Rollup.. let’s just say it doesn’t exactly inspire confidence. It does, however, make me want to install a new operating system. I’m just not sure I want another version of Windows.

For many users, myself included, Windows XP was never a viable alternative. It seemed too flashy and new at the time. The benefits of installing it in a production environment did not outweigh the inherent risks. I don’t think business users care if you call it “home version” or “professional”, it’s still XP, and not 2K. Don’t get me wrong; XP is still an excellent upgrade from the now defunct Windows ME operating system. It’s just that i think many business users were waiting for a Windows 2003 professional. But that day never came. Windows 2003 server was released, that solved the problem for all those running Windows 2000 server, but everyone on the Windows 2000 Pro train was forced to merge with the XP crowd.

I’m not quite sure what Microsoft was thinking when it decided to lump all users into one basket of eggs. Maybe they thought that by focusing on XP, for both business and home users, they could ensure a more stable and secure operating system for all. Were they simply listening to what the majority of their user base was asking for? Did they seriously think that business users and home users were looking for the same things? Only time would tell.

Today, from my perspective, XP appears to be a veritable hacker magnet. The never-ending onslaught of security updates and patches, service packs, and still more patches has reduced this operating system into what i like to call: an accident waiting to happen. In fact, XP turned out to be no more secure or stable than windows 2000. I have yet to see a vulnerability that affects 2K and not XP. What i have seen, on the other hand, is the exact opposite… problems that affect XP and not 2K. I can’t help but wonder if LongVistahorn will offer any real improvements.

Or will it be: One step forwards, two steps back..