Why Bazaar rocks, and the highs and lows of its use with Rails

Edd Dumbill — 2007-06-20T11:04:52Z

While Subversion is for many the source code revision system of choice, I've never stopped long with it myself. Why? Because it's mostly a fixed-up CVS, and doesn't fix the really gnarly problem with revision control: merging.

Mark Shuttleworth has written an insightful little article on the key aspects of merging source code. Some of the points he makes underpin my choice of revision control system.

For several years now I've been a very contented user of Bazaar, in its first arch-based incarnation, and now in its latter form. The key reason has been ease of merging.

While most articles praising Bazaar are reports of open source development, I've also found it very handy for small in-house teams working on web applications.

There are very often multiple arcs of development going on at once, and the ease of merging makes it easy to ensure that long-running development arcs don't get ridiculously far from the main trunk of development. Bazaar's merging also makes it easier for lead developers to police the merging of the code base.

Using Bazaar with Rails and other tools

Working mostly with Rails, one repeatedly runs up against the assumption that Subversion is the golden path for revision control. This is perhaps a little telling about the level of participation most Rails-based projects have reached.

The tools story for a Bazaar user is both good and bad.

The good

Deployment: the Capistrano deployment system has support for Bazaar. I've written previously about the technique I use to deploy my Rails apps.
Collaboration: Trac is a wonderful integrated bug database, wiki and source code browser. Although it's a little hard to find, the trac-bzr integration works very well, and happily moves Trac out of the Subversion-based assumption that you can only have one repository root per project.

The bad

Continuous integration: with Expectnation, we've had to roll our own continuous integration system ('system' being rather a grand word for a shell script on a cronjob...) Most of the CI systems currently popular seem to assume Subversion.
Editor/IDE integration: some early work exists, but it's early days. I've not yet found anything making me want to leave the command line.

Join the conversation about this post

A deployment pattern for Rails and bzr

Edd Dumbill — 2006-09-29T13:50:19Z

I can't get enough of the bzr revision control system, and I'm quite fond of Rails too. So, I thought I'd share my deployment setup for Rails applications using Capistrano and bzr.

Capistrano works on the assumption that you're deploying from a revision control system. Secondly, it requires that your deployment server is aware of how to access this system. This leaves you with various options, the most obvious of which are:

Host your source repository on your deployment server
Have your deployment server equipped with remote access to your source repository
Mirror your repository to your deployment server

Of these, option 1 is out for all but somewhat casual projects, option 2 either opens up your source repository more than I like, or needs fiddly tunnelling of SSH which I don't think Capistrano is up to yet (I only like to use key-based access with SSH, rather than password based access, which seems at the moment complicate life where Capistrano is concerned.)

I've opted for option 3. The pattern I use is this. On setting up the deployment server, I push a copy of the bzr repository to a private directory. Then, on deployment I first update that repository securely from the master repository inside my network, then export the new release locally on the server.

Here are the relevant bits of my Capistrano configuration:

set :repository, "/opt/repo_mirror/#{application}"

…

set :scm, :bzr
set :checkout, "branch"

…

task :before_update_code do
  `bzr push sftp://deploy.example.org/opt/repo_mirror/#{application}`
end

One big advantage of this over option 2, a remote source repository, is that only the changes are sent up to the server, and the bandwidth-intensive application checkout happens locally on the deployment machine.