Using Subversion with WordPress – Part 1: Creating Vendor Branches and Integrating your Existing Code

This article assumes that you’ve read the basic svn howto and the more specific one provided on the WP Codex but would like to try or need a setup similar to that described here on a page called: Vendor branches. 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.

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" ]

Comments 13

  1. Pål Brattberg wrote:

    Excellent walk-through! Thanks a bunch for assembling this in such a clear way.

    This is now required reading for our in-house wp-customization projects.

    Thanks again!

    Posted 18 May 2009 at 5:24 am
  2. elran wrote:

    thanks! i’m glad you found it useful.
    i actually wrote this post to help remind myself how to work with wordpress and svn vendor branches – i kept forgetting – then having to re-teach myself..

    Posted 20 May 2009 at 1:52 pm
  3. Joshua Burn wrote:

    Many thanks for the good list with plugins, i have a number of favourites to, like the all known “All IN SEO “as well as the easy privacy policy and also SEO friendly images (got some excellent results with it)and lastly pretty links (great for cloacking) affiliate links…

    Posted 12 Oct 2010 at 2:22 am
  4. Nuzha Roy wrote:

    Hey! I’m at work browsing your blog from my new iphone! Just wanted to say I love reading through your blog and look forward to all your posts! Carry on the superb work!

    Posted 06 Jan 2013 at 11:58 pm
  5. mygirlfund wrote:

    Note: the assets origin of this fund is from my father coffee and cocoa merchant market and I’ve the deposit documents which my late father issued to me ahead of his death which absolutely sure that the fund is 100% threat totally free.

    Posted 11 Mar 2013 at 1:13 am
  6. Ashli Dannelly wrote:

    At this time it looks like Movable Type is the top blogging platform available right now.

    (from what I’ve read) Is that what you are using on your blog?

    Posted 02 Oct 2015 at 9:12 am
  7. Daren Kibble wrote:

    kangen water

    Posted 21 Dec 2016 at 7:08 pm
  8. Wes Dorta wrote:

    I’m pleased with the way that techblog.touchbasic.com covers this type of issue! Usually to the point, sometimes controversial, always well-written as well as stimulating.

    Posted 23 Dec 2016 at 6:22 pm
  9. Ryan Zenger wrote:

    I enjoy your opinion on this topic and look forward to additional posts and comments here at techblog.touchbasic.com. Thanks!

    Posted 28 Dec 2016 at 12:06 am
  10. acompanhantes no centro do rio de janeiro wrote:

    Trata-se de um relação de experiência do trabalho que vem sendo realizado, fundamentado na Política Pátrio de
    Humanização iniciado pela Enfermagem e Serviço Social junto aos acompanhantes dos pacientes internados
    no 9° andejar de um enfermaria universitário do Rio de
    Janeiro. http://www.solidalmentealme.it/forum/member.php?action=profile&uid=25235

    Posted 17 Jan 2017 at 12:13 pm
  11. ig wrote:

    I was recommended this blog by my cousin. I am not certain whether this
    post is written by him as nobody else know such distinctive about my problem.

    You are incredible! Thank you!

    Posted 24 Feb 2017 at 3:04 pm
  12. Anonymous wrote:

    A com mais perfeição modo com brigar sistema, no entanto questionar-me.? que bem como agrupamento,
    caso contrário imagem convexo da princípio que criou….?! http://gaestebuch.computer-werkstatt-gross-gerau.de/index.php

    Posted 08 May 2017 at 8:35 pm
  13. jakudzaru wrote:

    look more info

    Posted 14 Aug 2017 at 8:48 am

Post a Comment

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