I’ve pushed an update to the repository on gitorious which includes fixes for the setup.py issue, support for some [likely] common Subversion configurations and a test suite. In addition to the installation issue Rob also reported that wasn’t able to clone his svn repository with gsc. Some investigation led me to realize the following cases weren’t supported:

• svn:externals specified with nested local paths (ie, “vendor/product”)
• empty directories in the Subversion repository with nothing but svn:externals set on them

Both now clone correctly.

One open question is what (if anything) gsc should do when you run it against an already cloned repository. I’ve envisioned it purely as a bootstrapping tool but received an email stating that it didn’t work when run a second time, so obviously it should do something, even if that’s just failing with an error message.

At Creative Commons we’re a dual-[D]VCS shop. Since we started self-hosting our repositories last year we’ve been using both Subversion and git. The rationale was pragmatic more than anything else: we have lots of code spread across many small projects and don’t have the time (or desire) to halt everything and cut over from one system to the other. This approach hasn’t been without it’s pain but I think that overall it’s been a good one. When we create projects we tend to create them in git and when we do major refactoring we move things over. It’s also given recalcitrant staff me time to adjust my thinking to git. Adjustments like this usually involve lots of swearing, fuming and muttering.

As I’ve become more comfortable with git and its collection of support tools, I’ve found myself wanting to use git svn to work on projects that remain in Subversion. One issue I’ve run into is our reliance on svn:externals. We use externals extensively in our repository which has generally made it easy to share large chunks of code and data, and still be able to check out the complete dependencies for a project and get to work[1]. More than once I’ve thought “oh, I’ll just clone that using git-svn so I can work on it on the plane[2],” only to realize that there are half a dozen externals I’d need to handle as well.

Last week I decided that tools like magit make git too useful not to use when I’m coding and that I needed to address the “externals issues“. I didn’t want to deal with a mass conversion, I just wanted to get the code from Subversion into the same layout in git. I found git-me-up which was close, but which baked in what I assume are Rails conventions that our projects don’t conform to. Something like this may already exist, but the result of my work is a little tool, gsc — “git subversion clone”.

gsc works by cloning a Subversion repository using git svn and then recursively looks for externals to fetch. If it finds an external, it does a shallow clone of the target (only fetching the most recent revision instead of the full history). The result is a copy of your project you can immediately start working on. Of course, it also inherits some of the constraints associated with svn:externals. If you want to work on code contained in an external (and push it back to the Subversion repository) you may need to check out the code manually[3]. Of course, the beauty of DVCS is that there’s nothing stopping you from committing to the read-only clone locally and then pushing the changes via email to a reviewer.

You can grab gsc from gitorious. There are also installation instructions and basic usage information in the README.

fn1. It’s also led to some sub-optimal software release practices, but that’s probably a different post.

fn2. Yes, I’ve actually encountered the “airplane” scenario; this either means DVCS advocates are prescient or I’ve been traveling way too much lately.

fn3. This is true because some repositories spell read-only and read-write access differently; both CC and Zope do this, so the svn:externals definitions are often written using the read-only syntax to make sure everyone can make a complete checkout.

First, install WordPress from a Subversion checkout; do:

$ svn co http://svn.automattic.com/wordpress/tags/2.6/

instead of downloading the .zip or .tar.gz file. Configure as directed.

Then, when a new version is available, log into your webhost and run:

$ svn switch http://svn.automattic.com/wordpress/tags/2.6.1/

from your install directory.

Done.

Note that you can also do something similar (but an order of magnitude more complex, at least for my brain) using git and git-svn if you want to version your local settings as well. Perhaps one day Asheesh or I will get that written up.

Someday I’ll write up my thoughts on distributed version control and “convention versus configuration”, which seem to overlap in this deployment. But not today.