FogCreek Kiln, Distributed Version Control Systems And Me
March 12th, 2010 @ 7:55 pm | Filed under Technical
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. 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!
Let me start by saying that while I’ve made a career out of building software on Microsoft’s platform with their tools, I’m not a die-hard fan who thinks the Microsoft way is the one true way. I like to think I’m relatively open minded and can see the benefits of one platform over another. As such I tend not to bother with Microsoft beta software and try not to listen to hype about not-yet-released products and technologies. I prefer to wait until things are released for real and then see what they’re like. I could cite many instances over the years where things haven’t lived up to the expectations but on the whole Microsoft get there in the end.
I read with interest that the next version of Windows will, at long last, feature a built in background switcher – called a “desktop slideshow”. You might think that since I wrote a pretty decent background switcher that I’d be gutted and cursing the name Microsoft but quite the opposite is the case. The reason I wrote 

Whenever I see people on the train typing away on a
Maybe I’m a fatalist. Or maybe I’m a realist. Either way, a thought occurred to me the other day. What if I’m crossing the road, run down and killed? Or I’m running across a field and struck by lightning – death being instantaneous. Or maybe I’m going to put a cheque in the bank to find it’s being robbed by a masked gang, overpower them, call the police, deliver the baby of the pregnant woman there and then (there’s always one), generally save the day, but trip on the kerb outside, fall down and break my neck, dead as I hit the ground.


Capture the image (same as before)
Podcasting (in case you don’t know) is a cool way to listen to your favourite radio show whenever you like on your iPod instead of at the allotted time it’s broadcast. The idea is that you subscribe to a particular podcast (such as the 
It’s the last part that’s surprised me the most. Since it’s an interview situation, you’re under a lot more pressure than in a normal day so there’s no point making that worse with an extremely complicated trick problem. The test is in fact very easy. You get to sit down with Visual Studio 2005 to write a single method for an already-existing console application. You’ve got a spec telling you exactly what it needs to do and some helper classes and methods to provide you with what you need. In essence you need to match all orders for a given customer and the code is already there to return all the customers and all the orders for a given customer. It should take no more than 10-15 minutes and when I wrote it some of us thought it was so easy that it would be a waste of time.
Now I know we’re not going to attract the creme de la creme to work on a hill above Halifax in Yorkshire even if we do score 8/12 on
Whatever I decided to do, I now know the one thing I’d bring with me. It’s a device that can prove to anybody that I’m from the future, it would let me listen to music when bored waiting for a bus and come in handy if I wanted to show my mother photos from her future (and to prove I am who I say I am). It is in fact my new