Viewing entries tagged with 'vcs'

Version Control Systems Posted on 23 July 2008 | Tagged , | Comments (4)

For a long while I have been using subversion as my main version control system (VCS). This was due to a few factors - firstly it's probably the most popular VCS out there, and secondly since I use it at work I know it like the back of my hand. While it is most definitely a momentus improvement over CVS, it always seemed like a bigger hassle than it needed to be - firstly I start and stop and then pick up little personal coding projects all the time, and its quite an effort to set up a repository. Then there's the question of where to keep it - having it online is definitely useful, but sometimes I want to code without a net connection, particularly on one of my trips back to visit family and friends in Blenheim. That's a three hour ferry trip each way, and the time I am there is spent with only a dialup connection, which is more hassle than it's worth. The other thing that is irritating is occasionally people want to help code something (ok, that doesn't actually happen that often, but it does happen :P). So I have to give them access to subversion, which one is a pain, two it means I have to trust their code since it's committed before I get to do it, and three, maybe, just maybe, more people would send code my way if there wasn't that annoyance (okay, that's probably just wishful thinking). So with distributed version control systems (DVCS) being all the rage these days, I decided to give them a try.

The difference between a distributed VCS and a centralised VCS is really just a matter of different assumptions. A centralised VCS assumes that all developers working on a project at any given point of time will have access to the VCS server, and that all code is stored in a central repository on this server. It also assumes that branches are rare, and that while you might have a development, stable, and a few feature branches lying around, branches are the exception, not the rule. Anyone who has worked on a project with more than a handful of developers knows this is definitely not the case. On the other hand, a distributed system lends itself to a much more flexible system of development - each 'checkout' of a project is it's own branch, and in fact it's own repository. While this initially sounds like it might be a nightmare - that's a lot of branches, DVCS's have very good support for tracking merges and handling conflicts, so it ends up being more hassle free than a centralised system, which generally have very poor support for these things.

When deciding to give a DVCS a go, the first program that popped to mind was, of course, git. Git has generated a decent amount of hype behind it, as it was originally developed by Linus Torvalds, the guy who was the original programmer for the Linux kernel, and still plays a large role in its ongoing development. He wrote git to manage the source of the linux kernel, after a disagreement between the kernel guys and the BitKeeper guys meant the kernel developers' free license for the proprietary BitKeeper system was revoked. Git has also been picked up by few prominent open source projects other than the Linux kernel - notably X.org and Ruby on Rails. So I decided to give git a try for a while and see how I like it.

I spent quite a while reading the documentation on git - it's a complex piece of software. After reading the introductory and basic usage a few times over, I felt I had grasped some of the basics, and so started to use it. The first thing I noticed about git was it is blazing fast - after using subversion for so long, which while not being horribly slow, does feel a little bit sluggish at times. Using a lightning fast application like git reminds you what responsiveness really is - you press enter and the text scrolls faster than you can read it. It is also very easy to set up your own git repository - just run a command in your working directory and git does all the hard work. So while initially everything looked good, after a few weeks I found myself beginning to dislike git. The reason for this is simple - it's written by a kernel developer, for kernel developers, and it shows. While it is blazingly fast, it is also pretty darn unintuitive to use. Part of this I put down to Linus' development of "take CVS as an example of what not to do", which for users coming from a CVS/subversion background is very confusing. The rest of it I just put down to kernel developers being the target market, which don't really have a reputation for being people who concern themselves with such trivial things as user friendliness. Git also tries to force you to do things its way - which is very orientated to how the kernel developers work. Sure, being able to handle having hundreds of developers in some sort of crazy web of trust is useful to a lot of people, but there is very little support for making it easy for old Joe Bloggs (aka me) to handle his little projects, or for a small group of deveopers to work on a project together with little hassle. I'm sure these things are easily possible with git - but with the complexity of git I'll be darned if I can figure out how.

So feeling a little disillusioned, I started to hear about another DVCS more and more commonly through the tubes of the blogosphere - bazaar. While initially I didn't pay it much attention - in my mind the only reason git was popular was because of the backing of the kernel crew, and the buzz about bazaar all seemed to come from the Canonical/Ubuntu crew, as Canonical sponsor the development, I just brushed it aside as more irrelevant hype. After seeing a few more blog posts of what seemed to be some cool features (a avahi branch sharing plugin in particular), I decided to take a closer look.

The first thing that struck about bazaar was it has a completely different focus than git - git was designed to be fast, but bazaar was designed for usability. That's not that to say that git can't be usable (well, one day ;)), or that bazaar can't be fast, but it is a different mindset. Bazaar is coded in python, which from what I read is less of a concious design decision, but was originally being used for a prototype, when they discovered their prototype was quickly outgrowing the software it was designed to be a test bed for. Being developed in python, the language everybody loves to love, there are a large number of plugins written for it. I think an extensible plugin system is a brilliant idea - it beats the screen scraping and data peeping tools that have historically been used for VCS integration.

Bazaar is a breeze to use, particularly if you've come from a subversion background. All the basic commands are there, and act pretty much as they do in subversion. Bazaar is also very flexible - it lets you choose if you want a centralised repository or not - when you do a 'checkout', whenever you commit a change, the changeset will be pushed to the repository you checked it out from. If instead of doing a checkout, you use the 'branch' command, all your commits are made locally, and can easily be pushed to the repository you got them from (or another repository) whenever you need to. And to answer the speed question - bazaar feels more responsive than subversion, and is more than fast enough for everyday use. It's not the lightning that git is, but it's still a snappy piece of software.

Add to this the wide range of useful plugins, and the ease of setting up a web accessible repository (bazaar can use http, ftp and rsync in lieu of not having bazaar installed on the server), and you have a winning DVCS in my mind. I use the bzr-gtk plugin, which gives some nice gui integration (accessed via commandline, eg to get a nicer gui diff, i use bzr gdiff instead of bzr diff), the avahi plugin to make sharing branches on local network easier, and the svn plugin to let me read from svn repositories (this is mostly just playing around!). All in all, I think I've found the VCS for me!