Kiln Harmony
One of the biggest new features is Kiln Harmony, which lets you operate on Kiln repositories using either Git or Mercurial. So you can push changes to a Kiln repo using Git and then pull them using Mercurial. This means that you never have to decide whether you want to use Git or Mercurial. Religious war: averted.
There’s a lot of magic that goes into Kiln Harmony. Rather than try to cram all that material into a little blog-post, we’ll be running a series of articles in the coming days on how Kiln Harmony works. We’ll take you under the covers into the details of our implementation, how we handle bizarre corner-cases, how we handle data formats that are more defined by their violations than their nominal structure, and more.
Kiln Harmony had three iron requirements: it had to be repeatable (you couldn’t get different repos on subsequent translation attempts), lossless (we couldn’t discard data just because it was hard to preserve), and idempotent (a given Git commit or Mercurial changeset had to always generate exactly the same counterpart for a given repository, with no exceptions—even across Kiln installations or with a side-trip through a site like GitHub or Google Code). This suggested to us a pretty straightforward architecture: every single repository would be stored both as Git and Mercurial on-disk, and we would write a daemon that synchronized changes between the two repositories.
Though I’m a happy FogBugz customer, I had previously ignored Kiln since I use Git. Now I’m wondering whether it would be helpful for me.
Update (2013-03-16): Benjamin Pollack:
We heard you, so beginning in Kiln Harmony, we’ll start looking through changesets, code, and file names, beginning the second you start typing. Not only does this get you the results you want faster; the feedback you get as you type helps you figure out what you’re looking for in the first place. On the Kiln team, we’ve found instant searches so useful that we barely ever go to the “real” results page, and we bet you will, too.
