25 ms·

Announcing Kiln Harmony: the Future of DVCS

224 points by df07 14y ago

cantastoria 14y ago
Are there really that many dev teams that use Mercurial and git at the same time? Honest question....
- msy 14y ago
  Isn't the question more 'how many dev teams contain frustrated devs that would be happier using git/mercurial but are forced to use git/mercurial?',
  - lnanek2 14y ago
    There might be a lot that would complain about being on CVS or SVN...these two are pretty modern, though.
  - fusiongyro 14y ago
    +1 from me. I don't like git but am getting forced to use it anyway.
  - dscrd 14y ago
    Such people are silly, since those two options are almost identical.
    - nmcfarl 14y ago
      This sentiment seems to be common amongst people who fought their way through git’s somewhat obtuse syntax first. People coming from the other direction (hg first), I know a lot of people who wish they could go back to mercurial, but for various reasons can’t.
      - dmiladinov 14y ago
        I went from using mercurial to git and I still have lots of respect for mercurial. I wouldn't mind the switch at all if I needed to work with a team who used mercurial, but personally I still just prefer git.
      - tseabrooks 14y ago
        I went from hg -> git in the last couple of years. I'd say they are "almost identical". The key difference is a slightly different mindset on merging and branching IMHO. It can be non-trivial for some of my more hard headed dev brethren to change their way of thinking once they've chosen a method and gotten in the correct mindset.
      - freshhawk 14y ago
        Yup, that's me in a nutshell. I used svk first and then moved on to mercurial. Then I had to learn git. I like the model for lightweight branches in git (bookmarks in mercurial) but the step backwards in UI is still irritating. I'm used to it at this point but teaching it to others is a constant source of pain ("git checkout -t/-b"!)
      - MBlume 14y ago
        Ugh, no, I fought my way through git first, and I didn't think hg was the same when I encountered it, I thought hg was nigh-unusable after I thrashed at it for a week.
- rco8786 14y ago
  More of an individual developer preference, vs entire team's preference. I prefer git, but my team opted for mercurial. Now(since we use kiln) I get to use git and my teammates can continue to use merc.
  - rockhymas 14y ago
    This makes it easier to bring on new team members who are more familiar with or comfortable with one DVCS. And the (admittedly slight) gains in productivity for some of your developers is a nice bonus.
- bhauer 14y ago
  I'm not aware of any, but I suppose this means you can use your preferred tools even if the rest of your team disagrees. For my home projects, I used Mercurial for a year since I preferred its command-line tools to Git. When workable GUI tools for Git appeared (starting with Github for Windows), I migrated to Git. Also, a small bravo to Fogcreek for using a screen grab from Windows. Windows is so uncool that we need some Windows screen shot affirmative action.
- dagw 14y ago
  The last company I worked at had a least a half dozen different dev teams working on more or less unrelated projects, all doing their own thing. While each team all used the same tools internally, the different teams used different tools and each team handled its own vcs hosting. I can imagine a company like that might want to get everybody on the same page, without forcing one team to give up their favorite tool.
- EnderMB 14y ago
  I work for an agency that often picks up work from large agencies or in-house teams and most of the time I find myself using either Subversion or Mercurial. We use Mercurial for our own projects, but one client uses Git, which I use at home and prefer it to Mercurial. It's a situation I imagine a lot of development agencies find themselves in.
bsimpson 14y ago
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.
- gecko 14y ago
  We do. Accounts with two users or fewer are free (http://www.fogcreek.com/kiln/StudentAndStartup.html http://www.fogcreek.com/kiln/StudentAndStartup.html), and established open-source projects are free (contact us).
  - bsimpson 14y ago
    I read your blog-post and went "oh yeah - kiln. I wonder how they compare to BitBucket and GitHub. Let's look at the pricing page. Oh, the smallest plan is $25/mo. Guess I'll keep my one-person startup on BitBucket then." If you want to compete with BitBucket and GitHub, you guys might want to feature the startup plan more prominently on your pricing page. The mention of it is so far below the fold that I didn't even see it on my tablet. (If you are primarily focused on enterprise, that's cool too. I just feel like the mindshare for DVCS is trapped in the more community-centric players.)
- mhp 14y ago
  Github's workflow, features and terminology are focused on open source projects and those projects tend to work in a specific way. Kiln is focused on providing features that fit better inside a business environment. For example, the idea of a pull request is a bit foreign in a business environment. Internally, almost all the code written eventually gets shipped, so the social interaction around pull requests doesn't fit exactly right. Joel explains it better than I can: http://www.joelonsoftware.com/items/2013/03/11.html http://www.joelonsoftware.com/items/2013/03/11.html
  - DannoHung 14y ago
    Eh? Pull requests are just a way to track work on a branch.
lifeisstillgood 14y ago
This is likely to be a painless (if it works) transition mechanism for companies that chose mercurial and now want to follow git. 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. 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. Edit Should not be knocking the technical effort and work here - just the strategy...
andrewgodwin 14y ago
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. 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? 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.
- gecko 14y ago
  I'll be publishing a series of articles that dive into the nitty-gritty of how Harmony works in the coming days, so I don't want to answer every single "How do you?..." question in this thread, but since you're the first one: Git octopus merges of N parents are exploded into N-1 commits, each of which has some Harmony-specific metadata in its changeset extras field. We then use this data both to reassemble the octopus merge, and to prevent you pushing a changeset that has one of the "fake" octopus merges as a parent.
  - andrewgodwin 14y ago
    That's how I thought it'd work, just curious. Looking forward to reading up how it works - I hope it's not too fragile.
rockhymas 14y ago
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.
- McP 14y ago
  It's not too hard to write a Mercurial extension to do that kind of thing. Copying the code for the EOL extension (http://mercurial.selenic.com/wiki/EolExtension http://mercurial.selenic.com/wiki/EolExtension) and modifying it would be a good start.
orclev 14y ago
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.
- mhp 14y ago
  Are you talking about the Kiln servers, or issues with client software? The servers are hosted, so you don't need to worry about any requirements or cross platform issues.
  - orclev 14y ago
    The servers. I was looking around on the site to try to find more info about Kiln, and one of the FAQs was the system requirements for the server (for companies that want to host their own Kiln instances I'd assume). With git or Mercurial I can spin up my own host in a variety of ways, or if I want something slicker I could host my own instance of github (not sure about BitBucket, but I suspect it likewise can be self-hosted). With Kiln if I wanted to go a similar route I need to have a Windows server with IIS and a variety of other dependencies.
    - mhp 14y ago
      Ah, that's old documentation. We host Kiln on our servers now, so we don't sell on premise versions that you'd have to install which makes this a bit moot. But if we do start to do that again, you would be able to spin them up the same way you'd spin up GitHub enterprise, with a VM: https://enterprise.github.com/faq https://enterprise.github.com/faq
      - dankoss 14y ago
        I'm surprised that it can't be self-hosted, since the product is explicitly directed at enterprise. Any company with a large or important codebase is likely to want completely secure control over their VCS. Anecdotally, at least, external hosting would never fly at my company.
gecko 14y ago
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 non-exhaustive list of edge-cases we translate: * 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) 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 how we handle all the above edge-cases beginning really soon.
- alexholehouse 14y ago
  I'm really looking forward to these posts - it seems like a lot of the problems you would have faced are specific examples of more generalized data integration issues. Accordingly, the approaches used may have more general applications, which would be cool to tease out from your implementations.
- lifeisstillgood 14y ago
  What test cases do you use? Oddly I do not know what cases the git / hg devs use so I would be interested in seeing test cases plus comments as much as anything
  - gecko 14y ago
    We have a fairly robust test-suite that covers all the corner cases we were able to find by trawling old/major Git repos, and then we have a Jenkins-powered server that does functional tests on a pile of major projects (Python, Ruby, PyPy, Vim, Git and Mercurial themselves, some other stuff I'm spacing) to make sure that what goes in also comes out. The test suite is kept tiny enough we can sanely run it locally; the functional test suite takes much longer, so it just runs in batches every hour or so, I believe. I'll double-check with QA and update this if I've got that off in any meaningful sense.
naner 14y ago
Cool project, two criticisms: - Nobody is asking for this. Why would I want my team to use two different DVCS interfaces to work on the same project? - It is difficult to trust that a Frankenstein DVCS will handle corner cases well.
- mixmastamyk 14y ago
  Don't use it that way if you don't want. You can read the announcement as, "kiln now supports git."
pjungwir 14y ago
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. [1] http://www.catb.org/esr/reposurgeon/ http://www.catb.org/esr/reposurgeon/
- gecko 14y ago
  That's pretty radically different. A closer analog might be hg-git, but the moment you say that you want the entire process to cleanly round-trip, you have to preserve all kinds of weird and corrupt data that the modern incarnations of the tools don't let you create (for good reason). There's also a lot of internal metadata, especially in Mercurial, where there are multiple valid ways to store a given concept, but only one will yield the right SHA for a given changeset. Not only did no existing tool try to handle these issues; they were all built in ways that would've made such preservation impossible. That's why we had to write our own from scratch.
noelwelsh 14y ago
There are things you have to really care about and things that just have to be good enough. Version control is in the latter. 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. In summary: anyone who has a pressing need for this product has their priorities wrong.
- addlepate 14y ago
  Good point, I agree.
- mhp 14y ago
  "Just use Git. Or Mercurial. It doesn't matter." Exactly! That's the whole point of Kiln Harmony. Use whatever you want, and let the rest of your team and company do the same. Allowing developers to use the tools they want to use and the ones that allow them to work the fastest should be your highest priority.
  - bitcartel 14y ago
    What if a developer is most productive using Bazaar, Fossil, Monotone, or perhaps Arch?
    - oblio 14y ago
      Well, even among developers there's clustering. So not many developers are "most productive" using those DVCS. Probably because they have never heard of them or never used them, but it doesn't really matter right now. If your name is Git, you're number 1 in the DVCS space. If your name is Mercurial, you're a distant 2. If your name is neither of them, only a few people have ever heard of you. Sort of like this: http://xkcd.com/435/ http://xkcd.com/435/
    - harshreality 14y ago
      Then she should use the obscure dvcs and use extensions/plugins if necessary to communicate with remote git and mercurial repos. A dev can't expect the outside world to cater to some relatively obscure choice of dvcs. You might as well ask, "What if a developer is most productive using cvs?" A change resulting in a short-term loss of comfort and productivity can lead to a long-term increase in productivity and equal comfort, but everyone who's used to something likes to think it's a global optimum instead of merely a local optimum. There is also benefit in using the same tools that other developers use when collaborating on a project.
aoetr 14y ago
This solves a problem nobody cares about. There is no "war": Git has won, Mercurial is irrelevant. Also companies will just standardize on one DVCS, and non-companies won't pay when they can use Github or many other services for free.
specialist 14y ago
I'm interested. Which is a new thing. Joel Spolsky's live demo of FogBugz & Kiln is the single best product demo I've ever seen. Ever. It's so good, anyone doing demos should watch it, just because. http://www.fogcreek.com/fogbugz/ http://www.fogcreek.com/fogbugz/ (just the video) http://fogcreek.wistia.com/medias/z6o7hhvio5 http://fogcreek.wistia.com/medias/z6o7hhvio5 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. But hot damn the (apparent) integration and workflow of these two products are quite polished. Very well thought out and very well executed.
- julianz 14y ago
  Yeah Joel was born to demo/present, wasn't he. I saw him at Webstock some years ago and it was a fantastic presentation.
cjbprime 14y ago
> This means that you never have to decide whether you want to use Git or Mercurial. Religious war: averted. 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. (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.)
- gecko 14y ago
  Git is certainly much more widely used in general for open-source, but there are plenty of major projects that are on Mercurial. Python, Vim, Mozilla, dovecot, Go, NetBeans, and mutt all come to mind really quickly. Something like Kiln Harmony means that you, as a Git user, no longer need to care that these projects are on Mercurial. And conversely, if they want to use a project that's in Git, they can, from the security of their Mercurial workflow.
- flurpitude 14y ago
  The Mercurial support is very welcome for those of us who found it a battle getting our employers to switch from SVN to Mercurial and don't want to go through that again. Unlike the transition from SVN to a DVCS, a transition from Mercurial to Git would not really be of any great advantage. And our code is not open source so it doesn't make much sense switching just because in the wider world Mercurial is out of fashion.
  - crisnoble 14y ago
    >...those of us who found it a battle getting our employers to switch from SVN to Mercurial... Any tips for someone still fighting resistance to move to a DCVS?
    - samspot 14y ago
      I don't know if this helps you, but try telling them that they can leave the 'distributed' part for later. At my company we still have a 'central' repository. We'd really need to know more about your companies objections to DVCS to give advice. I personally just started using mercurial local-only alongside svn, and as new projects started I would try to make mercurial the default repo for that project. This worked well for me, but my company is pretty laid-back about these kinds of things.
atesti 14y ago
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?
cgrubb 14y ago
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: git 208M git revision 6M git version 56M git control 19M mercurial 29.5M mercurial revision 1M mercurial version 7M mercurial control 6M Google trends of "git repository" vs "mercurial repository": http://www.google.com/trends/explore#q=git%20repository%2C%20mercurial%20repository&cmpt=q http://www.google.com/trends/explore#q=git%20repository%2C%2... update: 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 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.
- deleted 14y ago
  [deleted]
- ejp 14y ago
  You might want to include searches for 'hg revision' etc - mercurial suffers from having its command-line invocation different from its name.
  - niggler 14y ago
    unsurprisingly, 'hg ____' shows fewer results than 'mercurial ____' for the words the parent tested
    - thedufer 14y ago
      hg - 338M mercurial - 30M hg revision - 5.5M mercurial revision - 1.1M hg version - 60M mercurial version - 7M I'm seeing exactly the opposite. There's an argument to made to the effect that `hg` picks up a lot of things that have nothing to do with source control, but that's still a big difference.
krmmalik 14y ago
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).
- caw 14y ago
  Welcome to corporate. For business group A, I use RCS. For business group B, I use SVN. For my own personal stuff I use git. No joke. Mercurial, Perforce, Clearcase are also in use depending who you ask. I'm sure we have some CVS still in use somewhere, and I think Bazaar may be installed, though I don't know who uses it. Basically if it exists, we have it installed, and someone might be using it, somewhere among the order of 100k employees worldwide.
  - krmmalik 14y ago
    That would explain my naivete on the matter. I don't deal with corporate much at all. I guess it makes sense for the corporate environment in that case then. Thanks for clearing it up.
cmbaus 14y ago
The war was over before this release. Git won.
rscale 14y ago
I could be wrong, but I don't think the git/mercurial integration is the big point of Kiln. 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. 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.
- diminoten 14y ago
  It opens doors which were, until now, closed to the Fog Creek people. I bet this was said a ton: "I like their tools, but does it support git?" Now, the answer is: "Yes, it does." I'd say that's a tad more than a "cute feature".
  - rscale 14y ago
    I absolutely agree that Fog Creek needed to support Git, but I don't think Harmony sells meaningfully more than Git-only + hg-only would've. That's why I refer to it as a cute feature. Fog Creek's emphasis on how they achieved git support steered the discussion to be about the value of git/hg interoperability, rather than the value of Kiln for corporate developers. And it seems like the consensus is that git/hg interoperability is, at best, a nice-to-have.
    - mhp 14y ago
      I think that's a fair criticism. Point taken.
      - deleted 14y ago
        [deleted]
  - jwr 14y ago
    As someone who said exactly that and pays for FogBugz, but uses GitHub: now I read about what they did and think "why would they do that? It's a horribly complicated technical problem, I can't be sure they got it right, I'll stick to GitHub". So, still no money from me, unfortunately.
jiggy2011 14y ago
Do git and mercurial users get into flamewars? I would assume they are pretty well united in their hatred of centralised verion control systems.
- xradionut 14y ago
  Yes, but it's extremely silly since most hg users are also git users, not of their own choosing, since many popular OSS projects are hosted at GitHub. There's a "winner take all" rally amoung certain git fans, whom have lost their sense of history, equating popularity with quality. Ironic, since the creater of git should have just switched to Windows in the '90s, because it "won already".
- zem 14y ago
  I was walking across a bridge one day, and I saw a man standing on the edge, about to jump off. So I ran over and said "Stop! don't do it!" "Why shouldn't I?" he said. I said, "Well, there's so much to live for!" He said, "Like what?" I said, "Well...are you religious or atheist?" He said, "Religious." I said, "Me too! Are you christian or buddhist?" He said, "Christian." I said, "Me too! Are you catholic or protestant?" He said, "Protestant." I said, "Me too! Are you episcopalian or baptist?" He said, "Baptist!" I said,"Wow! Me too! Are you baptist church of god or baptist church of the lord?" He said, "Baptist church of god!" I said, "Me too! Are you original baptist church of god, or are you reformed baptist church of god?" He said,"Reformed Baptist church of god!" I said, "Me too! Are you reformed baptist church of god, reformation of 1879, or reformed baptist church of god, reformation of 1915?" He said, "Reformed baptist church of god, reformation of 1915!" I said, "Die, heretic scum", and pushed him off. -- Emo Phillips
cmars 14y ago
I'd rather have the opposite -- a client that can use multiple DVCS repositories while preserving the identity of commits.
azov 14y ago
Joel's very own article on the Law of Leaky Abstractions (http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...) 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: - How do I do blah? - Well, you type hg blah-blah - What's hg? - I fixed this bug on master - Where? - Oh, are you using mercurial? It's called a tip in your world 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?.. Really, just pick one system and use it. (hint - pick git :)
- jordigh 14y ago
  No, pick hg. :)
- sreque 14y ago
  Mercurial is definitely better.
- HeyLaughingBoy 14y ago
  I'm having a really hard time seeing that. I use version control both at work and for side projects at home. The only things I need to know are how to check out code, check in code, label and branch. Occasionally I create a repository. Rarely. If you gave me a GUI that just had those four functions, I wouldn't give a rat's ass what VCS was living under the hood.
  - azov 14y ago
    If it really was that simple, mastering a new VCS would take 5 minutes. But it isn't. If you need to branch, you also need to know how to merge. Then you'll need to know how to resolve conflicts. You probably need to know what branches are there and how to diff them. And since you know how to check in, it's just a matter of time before you'll need to know how to revert. That's just you alone - once you collaborate with someone else, you'll need to learn how to share code, push, pull, remote branches... There's a reason why your VCS has more than four commands.
daigoba66 14y ago
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.
nnq 14y ago
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: why tf did Git win at this? ...I use it every day, but if I try to look at it from the outside it's an UX horror: 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 you have to undertand how it works in order to use it, which is the greatest sin a piece of software can commit imho ...it's a great tool but at the same time utterly nightmarish if you stop to think about it instead if just using it on auto-pilot
- laureny 14y ago
  > ...I use it every day, but if I try to look at it from the outside it's an UX horror: weird terminology with worst possible choice of words, inconsistent terminology even in the docs, inconsistent argument naming, mostly incomprehensible error messages If a tool makes you productive, you make the effort to look beyond its flaws. Windows and git are just two examples.
  - nnq 14y ago
    funny way of putting them together :) ...especially since Git is UNIXy to the bone, in all the bad ways.
    - mercurial 14y ago
      I was thinking about the other day, and I disagree. The main beef I have with git is that it's NOT UNIXy enough. Instead of having one command for one thing, it has one command for several different things (eg, git checkout) which I find absolutely aggravating.
- pnathan 14y ago
  I have used hg for about four years now and have basically transitioned over to git. It's hard to explain why, exactly. Yes, network effect, but it's more: it's like git integrated deeply into the underlying model rather than trying to abstract over the model. I would call myself a power user - I am the clearcase->hg transition guy in what I do, I've designed/maintained an enterprise hg extension (guestrepos, look 'em up, they are amazing), use mq, etc. But I think that the fundamental win for git is that they don't abstract, and this allows clearer understanding of what is happening when things go pear-shaped. But, that's my opinion. I use both on a daily basis.
Camillo 14y ago
Well, at least we can all agree that bzr is dead.
jhancock 14y ago
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. 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.
- mhp 14y ago
  trello -> FogBugz integration - should adapt to any and all usages: https://github.com/danlec/Trello-Bookmarklet https://github.com/danlec/Trello-Bookmarklet kiln could have something more interesting. We're working on it.
rbanffy 14y ago
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. 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.
peterkelly 14y ago
This is extremely 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. (Please wait a couple of mins before replying while I don my flame-retardant suit ;)
cheez 14y ago
Is this really such a big need... Tech lead picks, and fills team with people who agree. Done.
martinced 14y ago
It's really tiring to see what the Spolsky and Atwood offsprings are coming up with... It's nearly always the same "idea": try to prevent users from having opinions and individuality. 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. 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. And StackOverflow is preventing individuality and allowing a few control freaks to reign king and decided what kind of thoughts people are allowed to have. In other words these guys think they've identified a "problem": individuality and personal opinions. And they think they have a "solution": control. 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). Which is normal: control freaks are going to love software restricting choices and individuality. 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. 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. Oh and, and even though I was an early hg adopter, I have to admit that git (and github) won big times. 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". I really hate the Spolsky and Atwood of this world because to me they love dictatorship. I'm for freedom and individuality, not for control freaks trying to decide how people should think / talk / code / use DVCSes etc. And thankfully there are way enough people like me so that these control freaks are never going to win. Even SO is going to be replaced the day something less bent on dictatorship comes along.

224 points by df07 14y ago

cantastoria 14y ago

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

msy 14y ago
Isn't the question more 'how many dev teams contain frustrated devs that would be happier using git/mercurial but are forced to use git/mercurial?',
- lnanek2 14y ago
  There might be a lot that would complain about being on CVS or SVN...these two are pretty modern, though.
- fusiongyro 14y ago
  +1 from me. I don't like git but am getting forced to use it anyway.
- dscrd 14y ago
  Such people are silly, since those two options are almost identical.
  - nmcfarl 14y ago
    This sentiment seems to be common amongst people who fought their way through git’s somewhat obtuse syntax first. People coming from the other direction (hg first), I know a lot of people who wish they could go back to mercurial, but for various reasons can’t.
    - dmiladinov 14y ago
      I went from using mercurial to git and I still have lots of respect for mercurial. I wouldn't mind the switch at all if I needed to work with a team who used mercurial, but personally I still just prefer git.
    - tseabrooks 14y ago
      I went from hg -> git in the last couple of years. I'd say they are "almost identical". The key difference is a slightly different mindset on merging and branching IMHO. It can be non-trivial for some of my more hard headed dev brethren to change their way of thinking once they've chosen a method and gotten in the correct mindset.
    - freshhawk 14y ago
      Yup, that's me in a nutshell. I used svk first and then moved on to mercurial. Then I had to learn git. I like the model for lightweight branches in git (bookmarks in mercurial) but the step backwards in UI is still irritating. I'm used to it at this point but teaching it to others is a constant source of pain ("git checkout -t/-b"!)
    - MBlume 14y ago
      Ugh, no, I fought my way through git first, and I didn't think hg was the same when I encountered it, I thought hg was nigh-unusable after I thrashed at it for a week.
rco8786 14y ago
More of an individual developer preference, vs entire team's preference. I prefer git, but my team opted for mercurial. Now(since we use kiln) I get to use git and my teammates can continue to use merc.
- rockhymas 14y ago
  This makes it easier to bring on new team members who are more familiar with or comfortable with one DVCS. And the (admittedly slight) gains in productivity for some of your developers is a nice bonus.
bhauer 14y ago
I'm not aware of any, but I suppose this means you can use your preferred tools even if the rest of your team disagrees. For my home projects, I used Mercurial for a year since I preferred its command-line tools to Git. When workable GUI tools for Git appeared (starting with Github for Windows), I migrated to Git. Also, a small bravo to Fogcreek for using a screen grab from Windows. Windows is so uncool that we need some Windows screen shot affirmative action.
dagw 14y ago
The last company I worked at had a least a half dozen different dev teams working on more or less unrelated projects, all doing their own thing. While each team all used the same tools internally, the different teams used different tools and each team handled its own vcs hosting. I can imagine a company like that might want to get everybody on the same page, without forcing one team to give up their favorite tool.
EnderMB 14y ago
I work for an agency that often picks up work from large agencies or in-house teams and most of the time I find myself using either Subversion or Mercurial. We use Mercurial for our own projects, but one client uses Git, which I use at home and prefer it to Mercurial. It's a situation I imagine a lot of development agencies find themselves in.

bsimpson 14y ago

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.

gecko 14y ago
We do. Accounts with two users or fewer are free (http://www.fogcreek.com/kiln/StudentAndStartup.html http://www.fogcreek.com/kiln/StudentAndStartup.html), and established open-source projects are free (contact us).
- bsimpson 14y ago
  I read your blog-post and went "oh yeah - kiln. I wonder how they compare to BitBucket and GitHub. Let's look at the pricing page. Oh, the smallest plan is $25/mo. Guess I'll keep my one-person startup on BitBucket then." If you want to compete with BitBucket and GitHub, you guys might want to feature the startup plan more prominently on your pricing page. The mention of it is so far below the fold that I didn't even see it on my tablet. (If you are primarily focused on enterprise, that's cool too. I just feel like the mindshare for DVCS is trapped in the more community-centric players.)
mhp 14y ago
Github's workflow, features and terminology are focused on open source projects and those projects tend to work in a specific way. Kiln is focused on providing features that fit better inside a business environment. For example, the idea of a pull request is a bit foreign in a business environment. Internally, almost all the code written eventually gets shipped, so the social interaction around pull requests doesn't fit exactly right. Joel explains it better than I can: http://www.joelonsoftware.com/items/2013/03/11.html http://www.joelonsoftware.com/items/2013/03/11.html
- DannoHung 14y ago
  Eh? Pull requests are just a way to track work on a branch.

lifeisstillgood 14y ago

This is likely to be a painless (if it works) transition mechanism for companies that chose mercurial and now want to follow git. 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. 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. Edit Should not be knocking the technical effort and work here - just the strategy...

andrewgodwin 14y ago

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

gecko 14y ago
I'll be publishing a series of articles that dive into the nitty-gritty of how Harmony works in the coming days, so I don't want to answer every single "How do you?..." question in this thread, but since you're the first one: Git octopus merges of N parents are exploded into N-1 commits, each of which has some Harmony-specific metadata in its changeset extras field. We then use this data both to reassemble the octopus merge, and to prevent you pushing a changeset that has one of the "fake" octopus merges as a parent.
- andrewgodwin 14y ago
  That's how I thought it'd work, just curious. Looking forward to reading up how it works - I hope it's not too fragile.

rockhymas 14y ago

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.

McP 14y ago
It's not too hard to write a Mercurial extension to do that kind of thing. Copying the code for the EOL extension (http://mercurial.selenic.com/wiki/EolExtension http://mercurial.selenic.com/wiki/EolExtension) and modifying it would be a good start.

orclev 14y ago

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.

mhp 14y ago
Are you talking about the Kiln servers, or issues with client software? The servers are hosted, so you don't need to worry about any requirements or cross platform issues.
- orclev 14y ago
  The servers. I was looking around on the site to try to find more info about Kiln, and one of the FAQs was the system requirements for the server (for companies that want to host their own Kiln instances I'd assume). With git or Mercurial I can spin up my own host in a variety of ways, or if I want something slicker I could host my own instance of github (not sure about BitBucket, but I suspect it likewise can be self-hosted). With Kiln if I wanted to go a similar route I need to have a Windows server with IIS and a variety of other dependencies.
  - mhp 14y ago
    Ah, that's old documentation. We host Kiln on our servers now, so we don't sell on premise versions that you'd have to install which makes this a bit moot. But if we do start to do that again, you would be able to spin them up the same way you'd spin up GitHub enterprise, with a VM: https://enterprise.github.com/faq https://enterprise.github.com/faq
    - dankoss 14y ago
      I'm surprised that it can't be self-hosted, since the product is explicitly directed at enterprise. Any company with a large or important codebase is likely to want completely secure control over their VCS. Anecdotally, at least, external hosting would never fly at my company.

gecko 14y ago

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 non-exhaustive list of edge-cases we translate: * 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) 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 how we handle all the above edge-cases beginning really soon.

alexholehouse 14y ago
I'm really looking forward to these posts - it seems like a lot of the problems you would have faced are specific examples of more generalized data integration issues. Accordingly, the approaches used may have more general applications, which would be cool to tease out from your implementations.
lifeisstillgood 14y ago
What test cases do you use? Oddly I do not know what cases the git / hg devs use so I would be interested in seeing test cases plus comments as much as anything
- gecko 14y ago
  We have a fairly robust test-suite that covers all the corner cases we were able to find by trawling old/major Git repos, and then we have a Jenkins-powered server that does functional tests on a pile of major projects (Python, Ruby, PyPy, Vim, Git and Mercurial themselves, some other stuff I'm spacing) to make sure that what goes in also comes out. The test suite is kept tiny enough we can sanely run it locally; the functional test suite takes much longer, so it just runs in batches every hour or so, I believe. I'll double-check with QA and update this if I've got that off in any meaningful sense.

naner 14y ago

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

mixmastamyk 14y ago
Don't use it that way if you don't want. You can read the announcement as, "kiln now supports git."

pjungwir 14y ago

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. [1] http://www.catb.org/esr/reposurgeon/ http://www.catb.org/esr/reposurgeon/

gecko 14y ago
That's pretty radically different. A closer analog might be hg-git, but the moment you say that you want the entire process to cleanly round-trip, you have to preserve all kinds of weird and corrupt data that the modern incarnations of the tools don't let you create (for good reason). There's also a lot of internal metadata, especially in Mercurial, where there are multiple valid ways to store a given concept, but only one will yield the right SHA for a given changeset. Not only did no existing tool try to handle these issues; they were all built in ways that would've made such preservation impossible. That's why we had to write our own from scratch.

noelwelsh 14y ago

There are things you have to really care about and things that just have to be good enough. Version control is in the latter. 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. In summary: anyone who has a pressing need for this product has their priorities wrong.

addlepate 14y ago
Good point, I agree.
mhp 14y ago
"Just use Git. Or Mercurial. It doesn't matter." Exactly! That's the whole point of Kiln Harmony. Use whatever you want, and let the rest of your team and company do the same. Allowing developers to use the tools they want to use and the ones that allow them to work the fastest should be your highest priority.
- bitcartel 14y ago
  What if a developer is most productive using Bazaar, Fossil, Monotone, or perhaps Arch?
  - oblio 14y ago
    Well, even among developers there's clustering. So not many developers are "most productive" using those DVCS. Probably because they have never heard of them or never used them, but it doesn't really matter right now. If your name is Git, you're number 1 in the DVCS space. If your name is Mercurial, you're a distant 2. If your name is neither of them, only a few people have ever heard of you. Sort of like this: http://xkcd.com/435/ http://xkcd.com/435/
  - harshreality 14y ago
    Then she should use the obscure dvcs and use extensions/plugins if necessary to communicate with remote git and mercurial repos. A dev can't expect the outside world to cater to some relatively obscure choice of dvcs. You might as well ask, "What if a developer is most productive using cvs?" A change resulting in a short-term loss of comfort and productivity can lead to a long-term increase in productivity and equal comfort, but everyone who's used to something likes to think it's a global optimum instead of merely a local optimum. There is also benefit in using the same tools that other developers use when collaborating on a project.

aoetr 14y ago

This solves a problem nobody cares about. There is no "war": Git has won, Mercurial is irrelevant. Also companies will just standardize on one DVCS, and non-companies won't pay when they can use Github or many other services for free.

specialist 14y ago

I'm interested. Which is a new thing. Joel Spolsky's live demo of FogBugz & Kiln is the single best product demo I've ever seen. Ever. It's so good, anyone doing demos should watch it, just because. http://www.fogcreek.com/fogbugz/ http://www.fogcreek.com/fogbugz/ (just the video) http://fogcreek.wistia.com/medias/z6o7hhvio5 http://fogcreek.wistia.com/medias/z6o7hhvio5 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. But hot damn the (apparent) integration and workflow of these two products are quite polished. Very well thought out and very well executed.

julianz 14y ago
Yeah Joel was born to demo/present, wasn't he. I saw him at Webstock some years ago and it was a fantastic presentation.

cjbprime 14y ago

> This means that you never have to decide whether you want to use Git or Mercurial. Religious war: averted. 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. (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.)

gecko 14y ago
Git is certainly much more widely used in general for open-source, but there are plenty of major projects that are on Mercurial. Python, Vim, Mozilla, dovecot, Go, NetBeans, and mutt all come to mind really quickly. Something like Kiln Harmony means that you, as a Git user, no longer need to care that these projects are on Mercurial. And conversely, if they want to use a project that's in Git, they can, from the security of their Mercurial workflow.
flurpitude 14y ago
The Mercurial support is very welcome for those of us who found it a battle getting our employers to switch from SVN to Mercurial and don't want to go through that again. Unlike the transition from SVN to a DVCS, a transition from Mercurial to Git would not really be of any great advantage. And our code is not open source so it doesn't make much sense switching just because in the wider world Mercurial is out of fashion.
- crisnoble 14y ago
  >...those of us who found it a battle getting our employers to switch from SVN to Mercurial... Any tips for someone still fighting resistance to move to a DCVS?
  - samspot 14y ago
    I don't know if this helps you, but try telling them that they can leave the 'distributed' part for later. At my company we still have a 'central' repository. We'd really need to know more about your companies objections to DVCS to give advice. I personally just started using mercurial local-only alongside svn, and as new projects started I would try to make mercurial the default repo for that project. This worked well for me, but my company is pretty laid-back about these kinds of things.

atesti 14y ago

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?

cgrubb 14y ago

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: git 208M git revision 6M git version 56M git control 19M mercurial 29.5M mercurial revision 1M mercurial version 7M mercurial control 6M Google trends of "git repository" vs "mercurial repository": http://www.google.com/trends/explore#q=git%20repository%2C%20mercurial%20repository&cmpt=q http://www.google.com/trends/explore#q=git%20repository%2C%2... update: 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 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.

deleted 14y ago
[deleted]
ejp 14y ago
You might want to include searches for 'hg revision' etc - mercurial suffers from having its command-line invocation different from its name.
- niggler 14y ago
  unsurprisingly, 'hg ____' shows fewer results than 'mercurial ____' for the words the parent tested
  - thedufer 14y ago
    hg - 338M mercurial - 30M hg revision - 5.5M mercurial revision - 1.1M hg version - 60M mercurial version - 7M I'm seeing exactly the opposite. There's an argument to made to the effect that `hg` picks up a lot of things that have nothing to do with source control, but that's still a big difference.

krmmalik 14y ago

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

caw 14y ago
Welcome to corporate. For business group A, I use RCS. For business group B, I use SVN. For my own personal stuff I use git. No joke. Mercurial, Perforce, Clearcase are also in use depending who you ask. I'm sure we have some CVS still in use somewhere, and I think Bazaar may be installed, though I don't know who uses it. Basically if it exists, we have it installed, and someone might be using it, somewhere among the order of 100k employees worldwide.
- krmmalik 14y ago
  That would explain my naivete on the matter. I don't deal with corporate much at all. I guess it makes sense for the corporate environment in that case then. Thanks for clearing it up.

cmbaus 14y ago

The war was over before this release. Git won.

rscale 14y ago

I could be wrong, but I don't think the git/mercurial integration is the big point of Kiln. 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. 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.

diminoten 14y ago
It opens doors which were, until now, closed to the Fog Creek people. I bet this was said a ton: "I like their tools, but does it support git?" Now, the answer is: "Yes, it does." I'd say that's a tad more than a "cute feature".
- rscale 14y ago
  I absolutely agree that Fog Creek needed to support Git, but I don't think Harmony sells meaningfully more than Git-only + hg-only would've. That's why I refer to it as a cute feature. Fog Creek's emphasis on how they achieved git support steered the discussion to be about the value of git/hg interoperability, rather than the value of Kiln for corporate developers. And it seems like the consensus is that git/hg interoperability is, at best, a nice-to-have.
  - mhp 14y ago
    I think that's a fair criticism. Point taken.
    - deleted 14y ago
      [deleted]
- jwr 14y ago
  As someone who said exactly that and pays for FogBugz, but uses GitHub: now I read about what they did and think "why would they do that? It's a horribly complicated technical problem, I can't be sure they got it right, I'll stick to GitHub". So, still no money from me, unfortunately.

jiggy2011 14y ago

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

xradionut 14y ago
Yes, but it's extremely silly since most hg users are also git users, not of their own choosing, since many popular OSS projects are hosted at GitHub. There's a "winner take all" rally amoung certain git fans, whom have lost their sense of history, equating popularity with quality. Ironic, since the creater of git should have just switched to Windows in the '90s, because it "won already".
zem 14y ago
I was walking across a bridge one day, and I saw a man standing on the edge, about to jump off. So I ran over and said "Stop! don't do it!" "Why shouldn't I?" he said. I said, "Well, there's so much to live for!" He said, "Like what?" I said, "Well...are you religious or atheist?" He said, "Religious." I said, "Me too! Are you christian or buddhist?" He said, "Christian." I said, "Me too! Are you catholic or protestant?" He said, "Protestant." I said, "Me too! Are you episcopalian or baptist?" He said, "Baptist!" I said,"Wow! Me too! Are you baptist church of god or baptist church of the lord?" He said, "Baptist church of god!" I said, "Me too! Are you original baptist church of god, or are you reformed baptist church of god?" He said,"Reformed Baptist church of god!" I said, "Me too! Are you reformed baptist church of god, reformation of 1879, or reformed baptist church of god, reformation of 1915?" He said, "Reformed baptist church of god, reformation of 1915!" I said, "Die, heretic scum", and pushed him off. -- Emo Phillips

cmars 14y ago

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

azov 14y ago

Joel's very own article on the Law of Leaky Abstractions (http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...) 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: - How do I do blah? - Well, you type hg blah-blah - What's hg? - I fixed this bug on master - Where? - Oh, are you using mercurial? It's called a tip in your world 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?.. Really, just pick one system and use it. (hint - pick git :)

jordigh 14y ago
No, pick hg. :)
sreque 14y ago
Mercurial is definitely better.
HeyLaughingBoy 14y ago
I'm having a really hard time seeing that. I use version control both at work and for side projects at home. The only things I need to know are how to check out code, check in code, label and branch. Occasionally I create a repository. Rarely. If you gave me a GUI that just had those four functions, I wouldn't give a rat's ass what VCS was living under the hood.
- azov 14y ago
  If it really was that simple, mastering a new VCS would take 5 minutes. But it isn't. If you need to branch, you also need to know how to merge. Then you'll need to know how to resolve conflicts. You probably need to know what branches are there and how to diff them. And since you know how to check in, it's just a matter of time before you'll need to know how to revert. That's just you alone - once you collaborate with someone else, you'll need to learn how to share code, push, pull, remote branches... There's a reason why your VCS has more than four commands.

daigoba66 14y ago

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.

nnq 14y ago

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: why tf did Git win at this? ...I use it every day, but if I try to look at it from the outside it's an UX horror: 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 you have to undertand how it works in order to use it, which is the greatest sin a piece of software can commit imho ...it's a great tool but at the same time utterly nightmarish if you stop to think about it instead if just using it on auto-pilot

laureny 14y ago
> ...I use it every day, but if I try to look at it from the outside it's an UX horror: weird terminology with worst possible choice of words, inconsistent terminology even in the docs, inconsistent argument naming, mostly incomprehensible error messages If a tool makes you productive, you make the effort to look beyond its flaws. Windows and git are just two examples.
- nnq 14y ago
  funny way of putting them together :) ...especially since Git is UNIXy to the bone, in all the bad ways.
  - mercurial 14y ago
    I was thinking about the other day, and I disagree. The main beef I have with git is that it's NOT UNIXy enough. Instead of having one command for one thing, it has one command for several different things (eg, git checkout) which I find absolutely aggravating.
pnathan 14y ago
I have used hg for about four years now and have basically transitioned over to git. It's hard to explain why, exactly. Yes, network effect, but it's more: it's like git integrated deeply into the underlying model rather than trying to abstract over the model. I would call myself a power user - I am the clearcase->hg transition guy in what I do, I've designed/maintained an enterprise hg extension (guestrepos, look 'em up, they are amazing), use mq, etc. But I think that the fundamental win for git is that they don't abstract, and this allows clearer understanding of what is happening when things go pear-shaped. But, that's my opinion. I use both on a daily basis.

Camillo 14y ago

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

jhancock 14y ago

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

mhp 14y ago
trello -> FogBugz integration - should adapt to any and all usages: https://github.com/danlec/Trello-Bookmarklet https://github.com/danlec/Trello-Bookmarklet kiln could have something more interesting. We're working on it.

rbanffy 14y ago

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

peterkelly 14y ago

This is extremely 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. (Please wait a couple of mins before replying while I don my flame-retardant suit ;)

cheez 14y ago

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

martinced 14y ago

It's really tiring to see what the Spolsky and Atwood offsprings are coming up with... It's nearly always the same "idea": try to prevent users from having opinions and individuality. 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. 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. And StackOverflow is preventing individuality and allowing a few control freaks to reign king and decided what kind of thoughts people are allowed to have. In other words these guys think they've identified a "problem": individuality and personal opinions. And they think they have a "solution": control. 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). Which is normal: control freaks are going to love software restricting choices and individuality. 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. 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. Oh and, and even though I was an early hg adopter, I have to admit that git (and github) won big times. 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". I really hate the Spolsky and Atwood of this world because to me they love dictatorship. I'm for freedom and individuality, not for control freaks trying to decide how people should think / talk / code / use DVCSes etc. And thankfully there are way enough people like me so that these control freaks are never going to win. Even SO is going to be replaced the day something less bent on dictatorship comes along.