Moving my SVN repository to xp-dev

For the last two years or so (I think), I have been keeping my code version-controled at assembla.com.

My code – that is, the code I write at home, most significantly my school-related code, but also more important stuff such as my never-ending Taki clone project.

Now please don’t think version-controlling my personal projects means I am organized. Version control is a cool thing for the cooly non-organized people who make a mess of their code often enough to swear in the name of the revert command. Like me! And of course remote version control also means back-up against hard disc issues.

So I chose SVN because it’s free and open-source and I know it from work; well, I know it from work because I installed it at work after years they have been using SourceSafe. And I chose web-based because I don’t feel like maintaining a local server installation, plus there’s the part where you can access it from anywhere and the remote backup thing. And I chose assembla because it looked good at the time.

Except I have just received a mail saying that they are going to cancel their free program (apparently they have announced that some time ago, but somehow I missed the message).

So I quickly Googled an alternative solution and found xp-dev, which seem to do everything I want. Signup and migration took about 10 minutes. There are short instructions here, except (by now?) you can import the repository dump through the web-interface, without emailing the support.

So far so good, but it’s only been a few hours…

(Edit: I came across this post that linked to this interview with the guy behind xp-dev. You might be interested in reading it. After all, you’re going to trust your dear code with this guy).

(Edit: apparently the spell checker of my Windows Live Writer was off when I originally wrote this post. I hope with the help of Firefox’s speller things are better now).

Concerns about Drupal Release cycle

In previous posts I preached for Drupal, and I feel I should amend some concerns; the first and foremost is Drupal release cycle.

Drupal major versions are not compatible with each other. They “break the API”. All the contrib modules need rewrite (contrib modules are 3rd party plugins, and you use them extensively). Themes (templates, designs…) need rewrite.

Major releases come, in theory, every year or so. So you have to upgrade you site every year. For me this is a major drawback. I haven’t been through this yet, but I will probably hate it.

There are two major versions supported at any given moment (right now it’s 5 and 6). But you can’t really buy time by skipping major releases (e.g. moving from 4.7 directly to 6). Well, maybe you can, but it’s problematic. One reason is that the official upgrade process is only from the previous version, 5 in this case. More importantly though: you can’t really use Drupal when it’s first released, so there aren’t really two functional version supported at any time.

Drupal 6 (D6) was released on February 2008. At that day, the compatible Views module released an alpha version, and today, we only have a release candidate for Views. I wrote about View in a previous post: it may be a contrib module officially, but I don’t think there are many Drupal installations that don’t use it. And with more peripheral stuff, it may take months before you have a first compatible release. The celebrated Zen theme, for example, only released an initial D6 version in May.

I use D6 for my site, with many modules still in RC, beta or even alpha stages. It’s probably not best practice, and I wouldn’t do it for an enterprise site. Even as such, though, I won’t be able to skip D7: the way I understand it, the day D8 is released, my D6 site won’t be supported anymore, but it will be many months more until I can actually replace it with D8 site.

Now in comparison, Joomla still supports 1.0.x, where 1.0.0 was released in 2005. It’s probably well worth upgrading to 1.5 by now. Yet however painful the upgrade is (I have no idea), once in 3 years it’s not unreasonable.

Drupal developers defend the release cycle fiercely (for example here), and I am not going to argue with people that do good work for me without requiring me to pay. However I think it’s a point well worth considering before you commit yourself to Drupal.