Bearfruit

If you’re thinking about using distributed version control (abbreviated DVCS) such as Bazaar (or git or mercurial) and you’re coming from a centralized version control system (VCS) like CVS or Subversion, you probably aren’t fully benefiting from the powerful tools of your DVCS. One exciting feature of DVCS is lightweight branches. These let you create branches that exist only on your local system - not shared with other users (unless you want to) and not polluting anyone else’s or a centralized server’s repository.

Here’s one way to use them:

First, if you work on a team you probably have a central storage where everyone commits to. So for example, sftp://server/home/groups/project-name. (the different DVCS systems support a huge variety of possible storage locations - it could be a windows share or https or whatever)

So when you work on a project, you will grab a copy of the code to work on locally. This is known as “branching” in a DVCS. Our project is called “project-name” so using Bazaar as an example we’d do something like this:

cd ~/Projects
mkdir project-name
cd project-name
bzr branch sftp://server/home/groups/project-name trunk


The key here is we’re giving our branch the name “trunk.” It’s common to skip the second and third commands in the above process and allow the vcs to create a folder called “project-name” for you and work off of this single branch, but then you wouldn’t benefit from lightweight branches.

Lets say that you have a bug to fix, it’s id is 1234. It’s not going to be too big, touching only 2 files. We’ll branch from our trunk like this:

bzr branch trunk bug1234


Then we’ll make our changes in this new branch, commit them, and merge them back into our trunk. We can also delete our “bug1234” branch. Now lets say we want to work on a nifty new feature. It could be awesome, or it could ruin everyone’s day. This is a pet project and will touch quite a few files over the course of a week or so. You don’t want your work on this project to prevent you from doing other tasks though, so you create a new branch:

bzr branch trunk nifty-feature


Then you do your work in this new branch. While you’re working you can bring in changes from your trunk as you and your team modify the code base. Once done you can create a patch to send to your peers for review. But if it turns out your assumptions were wrong and your idea causes more harm than good, you just delete your branch and forget it ever existed:

rm nifty-feature


When everyone is working on trunk, like in a typical VCS, branching and merging is intimidating. However when you make branching and merging small changes part of your every day routine then life is a breeze. Conflicts are infrequent and the change log is far more succinct. Also, you can make committing to your local branch a routine practice almost as common as hitting the save button in your editor. Since there’s no round trip time with the server the latency is practically immeasurable.

I want to thank Marc Tardiff for helping me understand this. I’ll be quick to admit that the concepts of DVCS can seem very foreign when switching from an older system. Give it time, you’ll get it. And don’t forget to ask for help.

I’d love to hear your tips and suggestions!