Third party SVN imports

Things have been a bit quiet on the blog for a while, mainly because I’ve been working on a couple of personal projects with a Django slant.

Django itself is a ‘relatively’ new technology and much of its spin off projects are in very active development. So much so that for some I’ve been having to work out of the SVN trunk to get the most up to date functionality.

For those of you that know me, I’m pretty risk averse. I’d much rather be working from a version release and this process left me with a couple of heart in the mouth moments when I’d not committed any of my local changes in to my local SVN repository.

So how does one really deal with third party imports? Strangely this is something that had never really caused me that much of a headache before.

Svn:externals

Initially I thought the simple solution would be to use svn:externals, however I quickly realised this would only apply to my working copy and would not allow me to make the necessary changes to the core files I required.

A bit on how people are using svn:externals

Merging two repositories

Ok not to be deterred I thought I could simply merge the upstream SVN repository and my local repository et voila. Nope there seems to have been a strange design decision to disallow merging between different SVN repositories.

Aisle Ten had the same problem. See solution 2

Beginning to run out of options…

At this point I began to wonder whether my logic was flawed and whether this was actually achievable, so off I went to the SVN book.

Duly I found a section on vendor branches, which seems to cover off exactly what I was looking for. After reading around the recommended svn_load_dirs.pl I began stumbling across references to a tool I’d looked at some time ago SVK

Enter an old friend

Some time ago I read a great article by Bieberlabs on SVK, and managed to do a pretty impressive merge directly in to the trunk of my repository which quickly saw me roll things back. At that point I figured I really didn’t know what I was doing with it and left it alone.

Actually in this context it is really useful and has simplifed things massively. Here’s how I’m using it:

1. Mirrored the project’s SVN repository (upstream repository)
2. Created a local branch of the mirrored repository
3. Sync any changes to my mirror from the upstream repository
4. Merge any changes to my local branch
5. Push any changes to my local SVN repository (downstream repository)

This allows me to check any updates locally before pushing them up to my local repository and hopefully have a few less flutters along the way.

I should probably point out at this point that svn_load_dirs will do the job, I’ve just found SVK to be faster in terms of not having to checkout a working copy of any the repository each time but the individual revisions which have changed.

For those interested, I found Chris McGrath’s post on SVK with Mephisto answered pretty much all my questions