Cleaning Up Revision Histories

A post in the the bazaar email group described a better approach (than I had been using) to manage merges from personal working branches. For example; If I wanted to commit a change to the project 'Foo', according to the post, I'd do something like this...

$> bzr init-repo foo-branches
$> cd foo-branches
$> bzr branch http://example.com/foo-trunk trunk
$> bzr branch trunk workbranch
$> cd mybranch
$> # hack, commit, hack commit, repeat as necessary
$> cd ../trunk
$> bzr pull
$> bzr merge ../workbranch
$> bzr commit
$> bzr push

What I've done above is to first create a shared repository. I do this because I'm going to be working with multiple branches of the same project. Then I branch Foo's trunk into my new shared repository. Next I branch the trunk (that's in the repository) to my personal working branch, make all the changes and as many commits as I want. When I'm done I go back to the trunk. Pull it to make sure it's up to date. Then merge in my changes. Once I've done that I commit them and push them up to the server.

If you're worried about disk space you can remove the working trees for any branch you're not currently working in.

Bzr to Git

I think it's safe to say that the Rails community has decided git is the distributed revision control tool of choice. Unfortunately for me I've been using bzr for the last year or so. Lucky for me it's easy migrate from bzr to git using svn as an intermediary.

svnadmin create --fs-type fsfs /path/to/svn/project
cd /path/to/bzr/project
bzr svn-push /path/to/svn/project/trunk
git-svn clone  -T /path/to/svn/project/trunk /path/to/git/project

Patch Bombing and Change Stashing

I ran across the term 'patch bombing' today, which could be defined as; "multiple application logic changes all rolled into a single source code commit", it's the opposite of an 'atomic change'

I found the term relevant to a background thought I've been pickling over lately....

It's not uncommon for me to be in the middle of adding a new feature when I run across a bit of crufty code that needs to be refactored. Which poses the problem; How do I do the refactoring with out mixing the change sets?

In the past I'd just make both changes and write one fat commit message explaining everything but I always thought this approach smelled bad. Then, Jay Fields blogged about 'using patch as subversion's stash' and turned me on to 'the power of git-stash'.

It turns out that Bazaar, which I'm using for my current project, doesn't directly support this operation either but Jay's patch-stashing approach works just as well for bzr as it does for svn.

Setting Up A Shared Bazaar Repository

Currently I'm using a Decentralized Shared Mainline Repository. Here's my recipe...

You will of course need a server that's accessible to everyone.

Create a group for project.

$> groupadd projectname

Create an login for each of the users who will have commit access to the shared mainline.

$> adduser --ingroup projectname username

Create a directory for the repostitory inside the web servers document root

$> mkdir /var/bzr/projectname

Set the project folders group to the project groups name

$> chown :projectname /var/bzr/projectname

Set the project folders permissions

$> chmod ug+rwx,g+s,o+rx,o-w projectname

Now you can push updates

$> bzr push bzr+ssh://hostname/var/bzr/projectname

If you need to provide anonymous access to the repository one way would be to serve it with Apache.

Alias /bzr "/var/bzr"
<Directory "/var/bzr">
 Options +Indexes +MultiViews +FollowSymLinks
  AllowOverride None
  Order deny,allow
  Allow from all
</Directory>

This would allow you to do something like this

$> bzr branch http://hostname/bzr/projectname

Bazaar Workflow Examples

I was poking around the Internet and found an excellent article describing various workflows using Bazaar (or any distributed VCS really) and thought it was worth sharing.

KanbanOnRails' Meta-Project

My current work related project is KanbanOnRails.

It's home page contains pretty much every thing you could want to know about the project but doesn't explain the meta-project at all. So I thought I'd do that here...

It turns out that I've stumbled into using a rather odd assortment of tools and services to manage this project, but it's working well, so I thought I'd share the recipe here.

I'm using Bazaar for revision control, Launchpad for project managment and Google Docs for most of the actual content.

There's really only two SCM tools out there that I would consider using right now; Bazaar and Git. I'm firmly sold on distributed SCM and from what I've seen so far these two have the brightest future.

I've decided to use Bazaar for this project and to try Git out on the next.

Distributed SCMs work best if you have some public web space available to share branches, with, mine's here.

I've generally preferred using Trac for project management in the past, it's a fabulous tool, but this time I wanted a third party host that could provide a permanent home for the project. That really only left me with one choice, Launchpad, which natively uses Bazaar. Currently none of the other project hosting services; SourceForge, RubyForge, Google Code, etc... support any form of distributed SCM.

I would of prefered a good reliable (free) public wiki for content hosting but wasn't immediately aware of one so I decided to use Google Docs. This is the most likely part of the recipe to change if Google's Wiki is ever released or I find a good alternative.