Likin' bzr

I've been using bzr for the past couple of months, and am liking it.

I'm not using it on any projects involving multiple people. All of my employer's code still lives in subversion repositories.

Rather, I'm using bzr for local, lightweight revision control. It sure is nice to be able to go into a directory tree where I'm whanging together a prototype, or where I'm working up some documentation; and to say

$ bzr init
$ bzr add .
$ bzr commit -m "New repository"'

And bingo, I can make changes and back out of them at will, with little fear of trashing anything. And of course, for technical writing it's nice to be able to refer to old revisions.

Lately I've started fiddling around w. bzr branch, building prototype web servers in one directory tree and occasionally pulling them out to a "deployment" branch. This feels a little more like working with subversion, but bzr lets me make local "checkpoint" commits, where some things are broken, without fear of breaking the build.

At this point my only problem with bzr is that I don't quite grok what's going on under the hood. Distinctions between branches and checkouts seem clear enough. But I don't understand why, when I commit from a "checkout" workspace, a subsequent bzr status in the source workspace will tell me that my workspace is out of date; whereas a similar sequence of actions from a "branch" workspace -- a commit followed by a push, followed by a status in the target workspace -- offers no warning that the code has been updated.

Given some time and experience these confusing behaviors should make more sense. Meanwhile, it sure is nice having cheap, local revision control. Kinda like XCode 3's Project Snapshots, but without the XCode :)

Technorati Tags:
bzr, revision control, software development