Upgrading Drupal Core With Vendor Branches and svn_load_dirs: Almost Perfect

Manual upgrades of Drupal core are more time-consuming and error-prone than need be. svn vendor branches can help, but it's still not perfect.

The critical thing to realize is that the basic unit of work in svn is the changeset. When I first started playing with vendor branches, I tried to take a shortcut and just diff two arbitrary branches anywhere in my repository. But without a changeset between two revisions, that will get you nowhere. svn can't automatically diff the branches - it will just delete every element and then re-add it. And that will only bring more chaos to a process where we are trying to restore order.

So we need to create a changeset between two revisions of Drupal. But remember why we want to automate upgrades in the first place. For major releases, this set of changes is going to be so complex that doing it manually would be prohibitively error-prone. It's also going to be a huge number of changes, which makes it time-consuming. What to do?


This script will look at a (source) set of files in an svn repository, compare it to a (destination) set of files, and then automate whatever adds, changes, and deletes are necessary to make the source like the destination. It will check the changes in for you, and it will optionally tag the changeset.

$ ./svn_load_dirs.pl http://my-svn-server.com/svn/minimalmedia/vendor/drupal/core current drupal-6.5 -t 6.5

If svn_load_dirs isn't already installed on your system, it can get a little tricky. You need to get svn_load_dirs.pl.in, rename it to svn_load_dirs.pl, then point it to your svn binary, which you can find like this:

$ which svn

Run svn_load_dirs with an older version of core as the source, and the new version as the destination, and we have a changeset that represents all the differences between those versions of core. Now we can merge that changeset with any other existing installation in the repository, and it will upgrade core without touching any of your contrib modules or themes. If you've hacked core at all, it should prompt you to perform a merge.

$ pwd
$ svn merge http://my-svn-server.com/svn/minimalmedia/vendor/drupal/core/6.4 http://my-svn-server.com/svn/minimalmedia/vendor/drupal/core/current .
$ svn commit -m "upgrading from drupal 6.4 to 6.5"

This worked beautifully for a little while, but there's a catch. Because I frequently partner with other developers, or work with code-savvy clients who need access, putting all my Drupal projects in the same repository won't work for me. And the catch is: you can't merge across repositories.

It would be nice, perfect actually, to have one repository where I maintain vendor branches, and upgrade core on all my Drupal projects from there. Having to maintain vendor branches in every repository that contains a copy of Drupal core is a hassle, but it works.


I really (really) don't want to turn this into a 'my SCM is better than yours' discussion but the problems mentioned above are (one of) the reasons why I've switched from SVN to Git. Git does require a bit of reading and a different way of thinking about version control but this (small) investment in time/effort really pays of in the end.

One possible way to use a vendor branch like approach with Drupal in Git:


I've been using SVN for quite some time and was rather reluctant to learn about Git (time is scarce :D) but in the end it was really worth it, especially when working with other developers or when using external components like Drupal.

You could also create a patch from one version of drupal to another and use the patch to upgrade your other repositories.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options