This is the archive for November 2005. Recent posts can be found at the main blog page.

How bzr changed my workflow

Monday, November 28, 2005 ★ 21:35 ★ Categories Programming, Misc ★ Permanent url

The last couple of months, I’ve been using Bazaar-NG as a version control system. Other version control systems like CVS and Subversion have been around much longer than bzr (the short name for Bazaar-NG), but I’ve never bothered really using those, since they are relatively hard to set up and require you to have a central machine where you store your versioned files.

In contrast, bzr works in a completely decentralized way. This means you don’t need a working internet connection to work with your versioned files, so that you can happily hack on your code while on a train, or even worse, on a plane! Of course, centralized version control systems do not prevent you to hack some code on a disconnected laptop, but they don’t allow you to commit, to browse the history or to revert to previous versions. All these benefits come standard with a decentralized system such as bzr.

A special hidden directory in your working tree, called .bzr/, is used to store all past revisions, commit messages and some other metadata about your tree. So, there’s no system-wide repository that needs setting up. Just bzr init in the directory you want to version and off you go! bzr add your files and bzr commit your first version. No cryptic commands to set up your repository, no configuration needed!

Not just code

Although version control systems have traditionally been used mainly for programming projects, there’s no reason you cannot use them for other projects like papers or other writings. Since it is so easy to use bzr, I use bzr for all my non-trivial projects: code (eg. Anewt), essays, config files (eg. my Vim configuration), living documents (e.g. membership lists). I really recommend that you do the same, as bzr offers you many benefits.

I’ll elaborate two use cases below. Note that I assume you use a plain text format for your texts, such as LaTeX. Other formats will also work, but you won’t be able to programatically calculate the differences between two versions (you can always compare by hand, of course, and you still get the versioning benefit).

Say, you are writing an essay, but you’re not quite happy with a specific section of it, so you decide to rewrite it. Just before you start rewriting, you commit your current version along with a comment (commit message) stating this is the version you had just before rewriting the aforementioned section. Now it’s time to rewrite your essay. No messing around with manually created backups with cryptic filenames like essay.tex.old1 when you can’t remember which version is which. If you’re done, you can compare the rewritten section with the old version. When you’re done, you can commit again stating this is the version after rewriting the section.

Another example: you decide to share your current version of your essay with a friend for proofreading. Since you’re still changing your own version while your friend proofreads it, it’s most likely page numbers containing specific sections or wordings have changed by the time your friend sends you his or her comments. Rather than trying to find the parts of your text your friend has complained about in your newer version, you can easily get your old version from the archive and review the comments your friend made on your previous version. It’s up to you whether to incorporate the suggestions in your newer version or to ignore the comments, if you think these suggestions no longer apply. You can take this sort of collaboration even further: if your friend also uses bzr, you can both have a directory with all the project files in it (this is called a branch). You can then bzr merge the changes your friend made into your own tree, letting bzr sort out the merging, placing conflict markers in your text if you both changed the same part of a file.

I can come up with plenty of other use cases, but I think you get the point by now.

More information on bzr

The bzr wiki features an Introduction to bzr as well as a Frequently Asked Questions page. You should really check these out if you want a more detailed description of what bzr can do for you.

Now is the time for you to act! Grab a copy and try it out for yourself.

OpenSSH and Bazaar-NG on Debian Sarge

Friday, November 18, 2005 ★ 15:33 ★ Categories Programming, Linux ★ Permanent url

James Henstridge wrote a bzr plugin that monkeypatches the built-in sftp (ftp over ssh) support, so that it uses OpenSSH instead of the Python only paramiko ssh implementation. James wrote about this in this blogpost on the bzr openssh plugin.

Although paramiko is no longer used for the ssh communication, several parts of the paramiko library are still used. This is a problem on Debian Sarge machines, which do not include paramiko packages. Installing these packages from the testing archive doesn’t work right away, since they depend on a newer glibc version than is available in Debian Sarge.

To overcome this problem, I’ve backported (simply rebuilt) the relevant packages for Debian Sarge, so that you can fully enjoy ssh support in bzr. I’ve made these packages available at: http://uwstopia.nl/files/2005/11/python-ssh/

Enjoy! Please let me know if you have any problems.

Update: The OpenSSH bzr plugin is obsolete, since the functionality has been enhanced and has now been merged with bzr itself.

Note: Paramiko is still used for the SFTP implementation though, so if you’re on Debian Sarge you will still need my packages!