Post Format

FogCreek Kiln, Distributed Version Control Systems And Me

4 comments

FogBugzI’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.

KilnSo 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.

A Kiln Changeset

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!

Posted by

Creator of John's Background Switcher. Scotsman, footballer, photographer, dog owner, risk taker, heart breaker, nice guy. Some of those are lies.

4 Comments Join the Conversation

  1. Great article. We’re looking at Kiln/Mercurial at the moment after many many painful SV merges and the more i read the more i’m convinced it’s the way forward.

    Reply

    • Yeah, it really does rock. I use SVN at work and every time I do anything with it it feels like stepping back in time from using Mercurial and all of its distributed goodness. It’s one of these things that once you start using it and get the hang of it you’ll never look back!

      Reply

  2. So you completely bailed on the idea of importing the historical check-in information from Vault to Kiln? That’s a bummer. I’ve been itching to switch over to Kiln myself, but can’t stomach the idea of leaving all the version information behind. I was hoping your article would point me to a way to manage the transition while keeping the history.

    Reply

    • It’s interesting that I thought not being able to port my history to Kiln would be a pain as I’d have to go into Vault to look further back in time but I’ve only actually done that twice. And now I think about it despite working on many different types of software over the years I’ve only found it helpful to be able to look back into the dim and distant past of software on very few occasions. I suppose that as software evolves, older incarnations of itself become a lot less relevant. Having full history in one place feels comforting but I’m not convinced it really matters as much as I thought it would.

      What I will say is that I’ve found Kiln to be immeasurably better than Vault for day to day development and well worth the very slight pain of having to fire up Vault to look at the history prior to switching to Kiln. I wasn’t entirely sure about DVCS and it did take a while to get used to but now I’m used to it I wouldn’t want to go back! Plus the FogBugz integration just gets better and better.

      Reply

Leave a Reply