I’ve been a long time user of FogCreek’s bug tracking / project management / customer support / jack of all trades / master of all system FogBugz for many years. I use it at work (where it sits in the centre of our development process, we all revolve around it) but more importantly (ahem) for my own projects such as John’s Background Switcher it’s indispensable – without it I’d be lost. It handles all my support emails, defect and feature tracking, it’s my documentation repository, I use it to create release notes and when I’m doing beta testing of JBS I use its discussion forum functionality. There’s nothing better on the market and it takes away all the pain associated with managing and developing software so I can concentrate on what I’m actually building.

I’ve also used SourceGear Vault for version control for a few years and it has the handy ability to hook into FogBugz such that when checking in some code I can associate it with a case in FogBugz. This means I can look at all the code changes for a given case and see what it was that made me break some vital piece of functionality, although there’s no automatic way to see cases related to a checkin.

My good friend John Topley has been telling me how great distributed version control systems (DVCS) are for ages now (regular readers will know that John is forever telling me how great something is and then 6-12 months later I realise that he’s always right and follow up – like buying a Mac, an iPhone and many other things). When I attended the Scotland on Rails conference last year with John I saw a demonstration of working with Git (one of the DVCS out there) and I was impressed.

Very briefly, instead of having a central repository that you get the latest copy of the source from, make changes then commit them, you clone the entire repository (with all of its history) onto your machine. You can make changes, commit them (locally) and then when you’re ready push all those changes up to your central repository. You can also choose when to pull changes from the central repository locally – the cool thing being that you don’t actually have to update your local source with those changes until you’re ready. This means super fast checkins (since you’re not going over the network) and you can work in isolation while being able to unwind changes without affecting other people. When you’re ready you push those changes out so that everybody else can pull them to their local repositories. Suddenly things like branching, merging, multiple development paths and a host of things that can be painful to do in systems like SVN are much easier. If you really want to know about distributed version control systems then read Joel Spolsky’s tutorial here – hginit.com. What, you’ve read it already? Let’s carry on.

So a while ago I heard that FogCreek were working on a version control system – called Kiln – that integrated seamlessly with FogBugz but I was a bit busy at the time so added it to my “to get back to” list. A couple of weeks ago I finally remembered to have a look at it and bought myself a license (knowing that I had nothing to lose with their no hassle money back guarantee). After installing I started importing the source from my projects into Kiln. The first problem I had was that Vault seems to have no easy way to export the source history but since I’ve still got Vault running I can always go back and find older versions if I need to (which I most likely won’t).

The import was easy and it then became a case of getting used to using Mercurial (which is the DVCS system upon which Kiln is built) and how it does things. Having read Joel’s tutorial again (and paying attention this time) I was quickly up and running. Even though I’m the only person who works on my own projects (by choice), being able to have multiple cloned local repositories means I can try radical things out, take advantage of source control while I do that and choose to push the changes into Kiln or just delete the lot. And I don’t need to mess around creating branches only to later delete them or go through the pain of merging them in. Ultimately it means the time between checking in can be a lot shorter knowing that only when I’m finished with a piece of work do I need to push it to Kiln. In a team environment this rocks – you don’t have to worry about colleagues picking up your half-finished work and them complaining when things have broken.

When you’re developing on Windows you can install the “Kiln Client Tools” which puts TortoiseHg and some addons onto your system and makes authenticating and cloning repositories from Kiln dead easy. If you’re on a Mac you can install Mercurial tools yourself and it all works nice and smoothly. Since there are plugins for most development environments (like Visual Studio and Eclipse) you can use Kiln (Mercurial) seamlessly as though you were using SVN with the added security of it being a DVCS. Welcome to 21st century software development. Sweet.

The FogBugz integration with Kiln gives what I like to call “360 degree traceability” (something my friend Ian and I love about Team Foundation Server). If I commit a change with something like “Case 123: Fixed the divide by zero error” as the checkin note and push that to Kiln, then automatically case 123 will show that commit on its case page so I can see the changeset details and likewise when looking at the history in Kiln there’ll be a link from that changeset to case 123 in FogBugz. When trying to find out why changes have broken other parts of a system this sort of visibility can be incredibly useful, particularly where a team of multiple developers work on the same code base.

Another cool feature of Kiln which is absolutely no use to me on my own projects is a powerful code review tool. I’ve never really done code reviews in any place I’ve worked – it’s seemed like there’s never enough time to do it. However looking at how easy it is to create and manage code reviews in Kiln makes me think that were I using Kiln at work in my team then we’d definitely start using them. You’d pathalogically avoid branching and merging in Visual SourceSafe because it’s horribly hard to do (since SourceSafe sucks) but using a system like Mercurial makes that so easy you don’t even think twice about it. And so it is with code reviews, they’re so easy to do in Kiln that there’s no excuse not to do them.

In summary I’m very impressed with FogCreek Kiln. FogBugz has set a very high bar in terms of quality and ease of use and Kiln sits as though it was there from the start. Next time I build a development team and choose the tools I’ll be going down the FogBugz / Kiln route for sure, I’d be an idiot not to!