Announcing Kiln Harmony: the Future of DVCS

Kiln Harmony is complicated, and has lots of edge-cases it needs to handle. We'll be publishing a whole series of blog posts that explore exactly how Kiln Harmony works. In the mean time, though, just because I think it might spawn some interesting discussion, here is a <i>non-exhaustive</i> list of edge-cases we translate:<p><pre><code> * Git octopus merges * Mercurial descriptions that are not UTF-8 * Git commits whose messages aren't in their nominal encoding * Mercurial and Git having invalid timestamps * Git having a different author from committer * Git and Mercurial commits and changesets with extra metadata * Mercurial usernames that are not valid Git usernames * Mercurial bookmarks that are not valid Git refs * Mercurial named branches * Git annotated tags (requires an not-quite-yet-released extension to fully round-trip; the non-annotated part of the tag works today and will be forwards-compatible) * Mercurial changesets/manifests/filelogs with bad parent data * Git trees that are just flat-up invalid * Subrepos and submodules (100% preservation, but we can only translate Git submodules/subrepos cleanly to/from each other, since Git submodules have to be Git) </code></pre> There's more, but hopefully that gives you some idea what we were up against. Again, I'll be publishing a series of articles that explore <i>how</i> we handle all the above edge-cases beginning really soon.

Joel's very own article on the Law of Leaky Abstractions (<a href="http://www.joelonsoftware.com/articles/LeakyAbstractions.html" rel="nofollow">http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...</a>) comes to mind. Kiln Harmony might abstract away which VCS system you use, but I think in the real world you will just end up having to know both systems (or finally standardizing on one). Think of communication, for example:<p>- How do I do blah? - Well, you type <i>hg blah-blah</i> - What's <i>hg</i>?<p>- I fixed this bug on <i>master</i> - Where? - Oh, are you using mercurial? It's called a <i>tip</i> in your world<p>IMHO this stuff alone makes using two almost identical but different version control systems within a team a bad idea. Then there's that another layer that is supposed to work transparently, but when you have a problem you're never quite sure... is there a bug in hg? git? kiln?..<p>Really, just pick one system and use it. (hint - pick git :)

There are things you have to really care about and things that just have to be good enough. Version control is in the latter.<p>Just use Git. Or Mercurial. It doesn't matter. They are just about the same and the minor improvement you might get from one over the other is just not worth the effort of thinking about it. Now go do something more useful with the cycles you save.<p>In summary: anyone who has a pressing need for this product has their priorities wrong.

&#62; This means that you never have to decide whether you want to use Git or Mercurial. Religious war: averted.<p>I think the religious war is already over, and Git won. The only time I hear about Mercurial is when Fog Creek talks about it; approximately everyone else is on Github.<p>(Update: For the record, I don't think Git winning this war was due to it being technically superior in any significant way -- but neither is Mercurial superior enough to make it worth teaching everyone how to use two different DVCSes. Git was good enough, and then it won the mindshare war, and now it's the standard.)

I've been doing Google searches every now and then to try to assess the relative popularity of Git vs Mercurial. Two years ago it seemed to be 2:1 in favor of Git. A year ago it seemed to be 3:1 in favor of Git. Now I think it is about 5:1 in favor of Git. Here are my most recent Google hit counts:<p><pre><code> git 208M git revision 6M git version 56M git control 19M mercurial 29.5M mercurial revision 1M mercurial version 7M mercurial control 6M </code></pre> Google trends of "git repository" vs "mercurial repository":<p><a href="http://www.google.com/trends/explore#q=git%20repository%2C%20mercurial%20repository&#38;cmpt=q" rel="nofollow">http://www.google.com/trends/explore#q=git%20repository%2C%2...</a><p>update:<p><pre><code> hg revision 5M hg version 55.5M hg control 63.M hg OR mercurial revision 6M hg OR mercurial version 70.5M hg OR mercurial control 74M </code></pre> The decline in popularity of "mercurial" vs "git" seems real, but I agree that "mercurial" searches may be under-reporting the popularity of Mercurial. The top hits for "hg -mercurial revision" have nothing to do with Mercurial, tho.

I'm interested. Which is a new thing.<p>Joel Spolsky's live demo of FogBugz &#38; Kiln is the single best product demo I've ever seen. Ever. It's so good, anyone doing demos should watch it, just because.<p><a href="http://www.fogcreek.com/fogbugz/" rel="nofollow">http://www.fogcreek.com/fogbugz/</a><p>(just the video) <a href="http://fogcreek.wistia.com/medias/z6o7hhvio5" rel="nofollow">http://fogcreek.wistia.com/medias/z6o7hhvio5</a><p>I don't know if I care about evidence based estimating. And I'm pretty sure FogBugz is overkill for my team's needs. And I'd rather eat glass that do anything Windows.<p>But hot damn the (apparent) integration and workflow of these two products are quite polished. Very well thought out and very well executed.

I have a hard time believing anything is the 'future' of version control if it doesn't have a free, public open-source plan. GitHub and BitBucket have huge amounts of inertia, and hence dominate in mindshare.

Since everybody is always repeating it and one can take Git being the "winner" of the DVCS "war" as a fact, I just have to ask: <i>why tf did Git win at this?</i><p>...I use it every day, but if I try to look at it from the outside it's an UX <i>horror</i>: weird terminology with worst possible choice of words, inconsistent terminology even in the docs, inconsistent argument naming, mostly incomprehensible error messages (yeah, they make sense after you dive into the docs to search for the thing mentioned in the message or you google for it, but that's not how it should be) ...and for anything more complicated <i>you have to undertand how it works in order to use it</i>, which is the greatest sin a piece of software can commit imho ...it's a great tool but at the same time utterly <i>nightmarish</i> if you stop to think about it instead if just using it on auto-pilot

Interesting - I was trying to get this concept to work a few years ago after I got a live SVN/Mercurial translator working, but it was very hard due to all the differences they note in this post.<p>One thing they don't mention is "octopus merges" - Git allows a merge to have more than two parents, while Mercurial does not. I'm sure there are other tiny edge cases, too; I wonder how they handle those?<p>Perhaps more to the point, I'm concerned that this means you're stuck using the lowest common denominator of both systems - for example, no hg bigfiles stuff.

This is likely to be a painless (if it works) transition mechanism for companies that chose mercurial and now want to follow git.<p>I respect fogcreek and avidly read everything Joel wrote at the turn of the century. But I had a years free kiln hosting that I must have used twice after setup and I just found GitHub so much cleaner and, well, it worked with git.<p>Being quiet for a year is not the sign of excellent planning and product management either - if they had this great plan 12 mths ago and knew it would take this long then go do it fine, but hire some oter guys to keep inching the rest of the product along - 12 mths is just dead. I am guessing they realised they had backed the wrong horse and tried to make a compatible product - when really just cloning GitHub and aiming at Joel's core sme market would work.<p>Edit Should not be knocking the technical effort and work here - just the strategy...

Are there really that many dev teams that use Mercurial and git at the same time? Honest question....

Is having to make a binary choice between Git or Mercurial, really that big a deal? I just assumed that teams would make a consensual decision, stick to one and get on with it. Seems like a great feat of engineering, but is it that wide a problem? (genuine question).

This is <i>extremely</i> impressive from a technical point of view, but I'm wondering if it's the wrong solution, given that arguments over a version control system are largely an organisational issue? Surely a better approach would be for everyone involved to negotiate and come to an agreement on the tool to be used, or have it mandated from on high.<p>(Please wait a couple of mins before replying while I don my flame-retardant suit ;)

How does this compare to ESR's reposurgeon tool? [1] I understand Kiln Harmony is a website, not a command-line tool, but it seems like they must have had to solve many of the same issues.<p>[1] <a href="http://www.catb.org/esr/reposurgeon/" rel="nofollow">http://www.catb.org/esr/reposurgeon/</a>

I suspect it'll be an uphill struggle. Like many pointed out, Git is good enough, it's free (as in beer as well as in speech) and ubiquitous. Where it's not is the domain of proprietary, hideously expensive and deeply entrenched (sometimes bundled with IDEs that run on only one OS) solutions their users hate, but corporate IT mandates the use nevertheless because it was not a user-driven decision.<p>This is crucial: it; s hard to sell software ir services to these clients by providing something great. You sell by making the CEO feel capable of making decisions like what DVCS their IT department should use.

I like the concept, but I have two objections to it. One, as pointed out by others, I'm highly skeptical of some of those edge cases. They mention a few of them at the end of that article, but they largely gloss them over saying they're dealt with automatically. My other objection is with Kiln itself. Not open source, not cross-platform, and even on Windows it seems to have strange requirements (like you can't run it on the domain controller). Sorry, any service that requires Windows is a automatic fail so far as I'm concerned.

Cool project, two criticisms:<p>- Nobody is asking for this. Why would I want my team to use two different DVCS interfaces to work on the same project?<p>- It is difficult to trust that a Frankenstein DVCS will handle corner cases well.

Do git and mercurial users get into flamewars? I would assume they are pretty well united in their hatred of centralised verion control systems.

Well, at least we can all agree that bzr is dead.

Kiln Harmony won't save as much money and angst as a DVCS that automatically converts tabs to spaces and back, based on personal settings, or one that changes bracket code formatting, but it's a start.

If being fully git/hg interoperable was holding back sales, I can understand their year-long investment. What is holding back me buying into FogCreek's products is tightly integrated Trello-Kiln-FogBugz. Hope you get to this soon.<p>oh, and for the love of all of us doing dev in China, can some of these SaaS's please put a server over here so we can reliably use your products. Trello's single page app works pretty well from China. Most don't. I'm stuck with redmine and other things I can self-host.

The war was over before this release. Git won.

I'd rather have the opposite -- a client that can use multiple DVCS repositories while preserving the identity of commits.

It seems as though having members of the same team mixing up mercurial and git. They have their own language and idioms. Think about trying to work together in such an environment. For some tools it's simply better for the team to homogenize than stay diverse. We're not talking about a text editor.

Since when is the version to be installed on our own servers unavailable? I always wanted to buy it once I have the svn conversion problems figured out. How long do existing FogBugz users have until the non-hosted version is removed from the market, too and how long are we able to get updates?

Is this really such a big need... Tech lead picks, and fills team with people who agree. Done.

I could be wrong, but I don't think the git/mercurial integration is the big point of Kiln.<p>Rather, harmony seems like an interesting side effect generated when Fog Creek built some swank tools for mercurial-based corporate developers, and git won the war while they were doing so.<p>Most of the value I see in Kiln is in the activity filters, the notifications, the code review tools, the ACLs, and FogBugz integration. Git/Mercurial interoperability is just a cute feature.

It's really tiring to see what the Spolsky and Atwood offsprings are coming up with...<p>It's nearly <i>always</i> the same "idea": try to prevent users from having opinions and individuality.<p>Atwood's discourse.org was supposed to be the "next generation of forums because the current forum aren't civilized enough": people supposedly aren't "civilized" enough to be able to have their own forums. No, one should use a forum engine made for and by control freaks that shall enforce civilized discourses.<p>Now this Kiln Harmony thing is supposed to "end the flamewar" between git/hg: people are allowed to have their own preferences anymore. Everybody is going to "win" because they'd be using the system created by and for control freaks.<p>And StackOverflow <i>is</i> preventing individuality and allowing a few control freaks to reign king and decided what kind of thoughts people are allowed to have.<p>In other words these guys think they've identified a "problem": individuality and personal opinions. And they think they have a "solution": control.<p>Interestingly enough when I just entered discourse.org to see how that one is catching up it seems to be the better ranked in... The republic of China! (no kidding here).<p>Which is normal: control freaks are going to love software restricting choices and individuality.<p>But I love my freedom. I love individuality and I think everyone should be free, including free to chose and say why they prefer hg over git or vice-versa.<p>So their "solutions" (discourse.org, Kiln Harmony) aren't going to be the "next gen anything" because there are too many individuals who value their individuality.<p>Oh and, and even though I was an early hg adopter, I have to admit that git (and github) won big times.<p>It's as if they realized they didn't bet on the correct horse (inherent qualities aside, I'm purely talking about market share here) and that hence they've been "owned" by people pointing out to them that git / github was winning. It's an argument they couldn't win: there's no way hg is as succesful as Git (once again: I haven't switched yet to git... I'm a long time hg user but I have to admit defeat here). So because they couldn't admit that they were wrong they decided to create an utterly complicated solution: "To put an end to the flamewar".<p>I really hate the Spolsky and Atwood of this world because to me they love dictatorship.<p>I'm for freedom and individuality, not for control freaks trying to decide how people should think / talk / code / use DVCSes etc.<p>And thankfully there are way enough people like me so that these control freaks are never going to win.<p>Even SO is going to be replaced the day something less bent on dictatorship comes along.