Thoughts on version control

September 18, 2008

I’ve used a number of version control systems, including CVS, PVCS, Subversion, and Arch. While people are scathing about CVS, I have to say that to my mind, the worst of the four is Arch. I tried using it because it had the right back-end storage, and discovered belatedly that its user interface was ghastly, with commands I found it impossible to remember how to use. Judging from its mailing list archives, Arch is dead, so I guess everyone else had the same experience I did.

Again considering those four, SVN was probably the closest to comfortable for me, and I still use it with projects like Ruby and its libraries. But for my own use, I’ve moved to something newer that I like better: Bazaar.

Bazaar was an attempt to do Arch again, but with a usable command set and the horrible file naming conventions removed. The developers clearly thought about the average user’s key requirements more carefully than the SVN developers.

For example, the first major release of SVN was designed to use versioned WebDAV for its file storage. Hands up everyone who has a versioning WebDAV server set up? Yeah, me neither. So they also gave it a dedicated server backend–but they made it store all your data in a virtual filesystem layered on top of Berkeley DB files. Those tended to become corrupt and need recovery. But hey, once they made SVN work on ordinary filesystems, it was pretty good.

No such stupidity with bzr. All you need is an FTP or SFTP server. If you want to publish changes but not allow people to commit, you can just point an ordinary HTTP server at your bzr repository and people can use the http URL to check out the code. This means if you have cheap $5 web hosting, you can run a bzr repository.

The commands are simple too. Suppose you’ve started a Java project in Eclipse and want to add it to bzr and publish it on a server somewhere.

$ cd ~/eclipse/workspace/MyProject
$ bzr init
$ bzr add src/**
added src
added src/com
added src/com/example
added src/com/example/myproject
added src/com/example/myproject/MyProject.java
added src/com/example/myproject/MyProjectTest.java
$ bzr push --create-prefix sftp://server.example.com/srv/bzr/projects/myproject/trunk
Created new branch.

Done. Now you can work on the code for a while, bzr commit each time you have it in a good state, and when you’re ready to publish the new revision just bzr push and it’ll use the same URL as last time.

If you later decide you’re too lazy to remember to bzr push and prefer the SVN/CVS way of working where there’s a central repository, then do:

$ bzr bind sftp://server.example.com/srv/bzr/projects/myproject/trunk

Now whenever you commit, your local copy will automatically be pushed to the server. Starting to work with someone else’s existing repository is easy too:

$ bzr get http://repo.example.com/projects/something/trunk

When you’ve made a bunch of changes you want to send to the owner for consideration, bzr send -o patches will bundle up all the necessary info into a file you can just e-mail–you don’t need a place to publish your branch. Or if you prefer the ‘auto-push’ model and are given commit access to the remote repository, you can do your initial checkout with

$ bzr checkout sftp://repo.example.com/projects/something/trunk

and then just bzr commit and bzr push your changes.

Of course, you can change your mind later and bind and unbind as you wish, or as your permissions change.

It’s also worth noting that by default, a bound branch (checkout) has all the necessary info to let you keep working if you find yourself unexpectedly without a network connection. Again, the designers of bzr obviously thought a lot about the way people work in the real world.

Meanwhile, it seems like the new hotness in version control is Git. Several open source projects I use have switched to it. I have to say, I don’t understand why.

There’s some discussion of git limbo from a Gnome developer that I think deserves reading before being tempted to use git. The idea of being able to do a partial commit easily is obviously very powerful, but it seems to me like leaving a loaded gun lying around.

I’ve worked with people who were in the habit of doing partial commits, and they were also in the habit of making the main trunk unbuildable. They’d fairly regularly commit a set of files that didn’t match any boundary of the version dependencies. This is particularly prone to happen during refactoring; it’s easy to change a library API, and forget to include one of the files that contains a call to the library when you’re checking in.

Besides, why do a partial commit anyway, when you could just turn what you think would be a good partial commit into a new branch, check that it builds and passes the unit tests, and then merge it? Isn’t that the whole point of having a VCS with fast lightweight branching?

As Eric Sink puts it,

Some folks say that Git’s killer feature is its index. That’s like saying that C’s killer feature is the ability to cast an int to a pointer.

Sure, git is fast. But bzr is faster than git 1.0, which was deemed fast enough. Meanwhile, “someone will write a GUI” is a lousy excuse for git’s horrible command line UI. The merge command should be ‘merge’, for example, not a variant of the ‘pull’ command. To me, git’s commands have Arch smell, and that’s not a good smell.

Filed under: Programming | Comments (1)