One of the major tasks we wanted to accomplish on the Fog Creek World Tour was to teach people about distributed version control systems, such as Mercurial. A lot of people have been clamoring for a video of the talk we gave, so I’m happy to announce that we’ve finally got it live:

One of the things we struggled with when trying to design the talk was how to bring people up-to-speed on the basics of distributed version control, and get them to understand why distributed version control was so amazing. Our solution was to break the talk into two pieces: the first part covers the very basics of Mercurial, the how do I use this?. The second half discusses some of the workflows that are hard in traditional systems, but really easy in distributed ones, the why do I want to use this?. Finally, there’s a long question and answer session at the end that’s probably interesting regardless of your skill level.

Saw the video, and liked what you saw? Take Kiln for a test drive! You can even follow along with the talk, learning Mercurial and playing with the very same workflows we discuss in the video.

When we launched Kiln, I knew we were solving a bunch of major problems that users actively had. I knew that because every time that I talked to someone, and walked them through what Kiln was capable of, they got really excited and asked piles of questions of how they could integrate Kiln into their current workflow.

But there was one question that just kept coming up time and time again:

How do you version databases?

I really empathize with this problem, because it impacts every single web application I write. It’s easy to version your code, to version your documentation, to version your images, to version your deployment scripts. But versioning the database schema gets hard. For really big systems, you end up needing piles of migration tools, but for most stuff, that’s overkill. You just need a simple way of tracking and applying changes to your schema. Using version control to store your migration scripts ends up being this weird version controlling your version control.

The great folks at Red Gate actually already came up with a good solution to this problem, called SQL Source Control, which allows you to version your schema, and even optionally your data, right inside your existing source control system. The only problem is that, up to now, it only worked with traditional SCMs.

The key words being: up to now.

Red Gate and Fog Creek are both happy to announce that SQL Source Control 2.1 now includes full support for Mercurial, meaning you can now trivially version your database schema in Kiln. And because SQL Source Control ultimately just works with the SQL statements that generate your database, it’s easy to make sense of the diffs from within Kiln. You’ll finally be able to bring the power of DVCS and Kiln to your database.

If you’d like to try it out, there’s a 28-day free trial available that will let you play with SQL Source Control and see how it integrates into your workflow.

One of the first FogBugz plugins available after the FogBugz Plugin API was released was the very handy BugMonkey plugin. I’ve had some fun tweaking FogBugz, like removing the time from date displays, reversing the order of bug events, and using BugMonkey to add syntax highlighting to BugMonkey. BugMonkey has helped a lot of people implement custom views or workflows that didn’t make sense as FogBugz features.

Meanwhile, Kiln has been growing as a product, and has reached the point where a level of customization makes sense. Of course, we had the Kiln API and Web Hooks, but those only addressed external tools. If you wanted to change the interface, you were limited to using Chrome or GreaseMonkey user scripts, like Kiln Hash by John Isaacks.

To alleviate that dependency, we are introducing Kiln Glaze, a port of BugMonkey to Kiln. To access Kiln Glazes, click the “My Settings” dropdown and select “Kiln Glazes”. Glaze is initially disabled, so a site administrator will have to click “Enable Glaze”. Once it is enabled, you will see a interface that is very similar to BugMonkey:

The syntax is also very similar to BugMonkey. There are single-line fields for name:, description:, author:, and version:. Following that are two multi-line fields, js: for any Javascript code and css: for any CSS styles. For example, John’s “Kiln Hash” Chrome extension is very easily converted into a Kiln Glaze:

name:        Changeset Hash
description: Shows the changeset ID for each changeset in a list.
author:      John Isaacks and Tyler Hicks-Wright
version:     1.0.0.0

js:
$('[id^=changesetList] tr').each(function () {
  var tr = $(this);
  var sid = tr.attr('sid');
  if(sid)
  {
    var first = $('<span>')
                    .addClass('csetHash')
                    .text(sid.substring(0,10));
    var rest = $('<span>')
                    .addClass('hashRest')
                    .text(sid.substring(10))
                    .hide();
    rest.appendTo(first);
    tr.find('td span.changesetDescription').append(first);
  }
});
$('.csetHash').hover(
  function(){
    $(this).find('.hashRest').css('display','');
  },
  function(){
    $(this).find('.hashRest').css('display','none');
  }
);

css:
.csetHash
{
  color: #777;
}

Which results in the changeset IDs being visible on each line: 

One note about Kiln Glazes: we do not consider our DOM or JavaScript to be part of a supported API, so it may be possible for element IDs or classes to change without warning. From our experience with BugMonkey, this is usually not much of an issue, since existing DOM and JavaScript does not change that often, but it is something to be aware of.

That said, have fun with Glaze, and if you come up with any that you think other people might be interested in, please post them to the Kiln StackExchange!

Few people know this, but Kiln started life as nothing but a review system.

Tyler and I both wanted to have a code review system to help us at Fog Creek, and disliked all of the available ones, so we wrote one up that used Mercurial’s branching and merging tools to have a saner workflow for fun as part of a competition. To make that work, we had to give Kiln basic repository hosting abilities. After we brought Kiln in-house, we drastically built up the project hosting capabilities and redefined the product as a complete distributed source control system, but the review system, in more-or-less its original form, stayed with the product as a major feature.

Unfortunately, the review system we came up with was based on FogBugz, and while that system worked great for Fog Creek, it simply didn’t fit a lot of teams very well. Kiln reviews, like FogBugz cases, could be assigned to only one person at a time. This worked great for making sure that a single person was always responsible for a review, but ended up getting in the way of the inherently collaborative nature of improving source code: each developer’s thoughts on the code would end up in its own code review. While they were linked, assembling a coherent picture of all comments on a given piece of code was much harder than it should’ve been.

So we went back to the drawing board, and for Kiln 2.4, came out with an entirely new way to do reviews.

Beginning today, Kiln reviews can have many reviewers, and reviewers can be added or removed at any time. Each reviewer can independently indicate that they approve or reject the changes and comment on the code.

If all reviewers reach a consensus, the review is automatically marked “approved”, and the review opener is notified that the changes have been collectively approved or rejected. If the reviewers cannot reach a consensus, the requester can leave the review open until a consensus can be reached, or can acknowledge the stalemate and close the review with a brand-new status of Abandoned.

This posed a slight issue for us: one of the best things about Kiln is that it integrates extremely tightly with FogBugz, meaning you can see reviews you’re responsible for right alongside your bugs and feature requests. We didn’t want to give up that ability with the new system. So what we did was add a new filter option to FogBugz, “My Code Reviews”, and a new search axis, reviewedby:me, so that you can easily find the reviews that are waiting for your feedback.

We feel that this new system is the best of both worlds:

1. Reviews now have lots of reviewers, so conversation all takes place in a single case–not a collection of related cases.
2. At the same time, everyone is still fully responsible for actually weighing in. While you can abstain from reviewing, that gets logged, and Kiln resists closing reviews before assignees have made a decision and recorded it.
3. And we’ve done this without losing our tight integration with FogBugz.

The new system ships out today to licensed customers, and has been available on Kiln On Demand since late last week. If you haven’t yet had a chance to give Kiln a spin, now’s a great time to sign up for a free Kiln trial so you can play with the new review system first-hand. We think you’ll like what you see.

One of the things that I mentioned when I discussed the importance of having a mission is that the Kiln team’s real purpose in life is to bring the awesomeness of distributed source control to as many people as possible. While we do a lot of that by making Kiln into the best source code management system available, we’re hardly doing it alone: Kiln builds off the amazing base provided by the Mercurial distributed version control system. Mercurial helps make Kiln what it is. For Kiln to really achieve what we want it to achieve, we need to help Mercurial itself shine, too.

This year, at Fog Creek, we’re doing that in two different ways:

1. First, we’re helping sponsor the Mercurial 1.9 code sprint. The code sprint is where the Mercurial developers have a chance to talk face-to-face to solve outstanding issues, agree on how to implement major new features, fix piles of bugs, and so on.
2. Second, we’ll be sending one of our own Kiln developers so that we can contribute some actual manpower to the bug fixing and feature development that goes on at the sprint.

This kind of paying back to open-source software is becoming increasingly common. Even when StackOverflow was brand-new, Jeff and Joel were already donating to support the projects that made StackOverflow possible, and they’ve kept up that tradition as StackOverflow has grown. I think this is a great way to pay back the open-source community, and to help further the creation of more great open-source tools.

If you’re interesting in helping the Mercurial project, the easiest way to help them out is to donate to the project or the sprint.