Question

I'm not asking the question "why don't you support my favorite feature X?". Instead, I'm interested to understand the decision. If there is something that I don't know about Mercurial (or Git for that matter), I'd like to know as I may counsel my teams to use Mercurial instead of Git.

I get a lot of push-back from the developers on Git. We know that SVN is a poor choice for what we do. We know that we need bona fide branching. What about Mercurial made it the choice for the first implementation?

Answer 1

http://qa.debian.org/popcon-graph.php?packages=git%20mercurial%20bazaar&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date&to_date&hlght_date&date_fmt=%25Y-%25m&beenhere=1

Answer 2

I agree that Git and Mercurial are very similar and enjoy both. I think my "slight preference for Git" comes from the different way in which each handles changesets. Mercurial requires you to instruct it to forget changed files that are not in your .hgignore file. Git takes a more proactive approach in that it requires you to add any changed files to your next commit. I think Git's approach is superior in that it is more explicit. I've also found merges with Git to be far smoother, but I can't substantiate that.

Answer 3

UPDATE: Kiln Harmony now supports both Git and Mercurial, natively, with the same repositories! Read more here.

When you ask why Kiln chose Mercurial, there's really two questions:

1. Why is Kiln based around a DVCS?
2. Why did Kiln choose Mercurial, specifically?

Why is Kiln based around a DVCS?

Because DVCSes provide real branching. As you know, managing branches in Subversion, CVS, and similar tools inevitably proves to be an extremely frustrating experience. Because Subversion before 1.5 does not record merge history at all, and even the most recent versions cannot use that metadata constructively, merging always ends up being an incredibly labor-intensive, error-filled process. As such, maintaining branches, even if technically possible, ends up being such an incredible pain that developers generally try to avoid using branches at all costs. Instead, what inevitably ends up happening is you end up with developers always developing in trunk, and, on rare occasion, making "branches" that are little more than snapshots of your point releases.

All of the modern, DAG-based DVCSes, including Git, Mercurial, and Bazaar, know exactly when and where you last merged. They have special "merge" objects in their histories, and even bring over the history of everything you're merging in. As a result, they can trivially handle complicated merges automatically that cause Subversion and similar tools to vomit, and you yourself can trivially see, at any point, what you have and have no merged between branches.

And why does that matter? Because real software shops have to maintain several versions of a product simultaneously. Just because you shipped version 2.0 doesn't (usually) mean that you can quit providing support for version 1.0. In a classic VCS, such as Subversion, you've got to make separate commits to the bug fix on every branch you care about. There won't be any direct indication that it's the same fix in both versions, no way to track what fixes got merged and when. Verifying that any given feature actually got in becomes complicated.

In a DVCS, that's not true. Merging goes easy, because the tool knows what you want to merge. Verifying that the bug fixes to 1.0 ended up in 2.0 is as easy as making sure that the commits from 1.0 appear in 2.0. Parallel development suddenly becomes really easy.

This is the killer feature that we believe make all DVCSes awesome, and a huge step forwards from tools like Subversion and CVS. And it's why Fog Creek has decided to place itself solidly in the DVCS proponent camp with Kiln.

Why did Kiln choose Mercurial over other DVCSes, such as Git?

We'll be honest: we love Git. It's ridiculously fast, the Ruby community loves it, it's powerful enough to handle massive projects like the Linux kernel, and it has a really cool community built up around sites like GitHub, which is kind of like a Facebook for developers.

But we also like Mercurial. It's nearly as fast as Git, it's really extensible, it has really great Linux and Windows GUIs, it also manages really big projects like Firefox, Python, Java's OpenJDK, and OpenSolaris, and it has a really awesome community of its own through Google Code and Bitbucket.

In fact, both Mercurial and Git are so close from a features perspective that we honestly don't understand the bickering. They're both DAG-based DVCSes. They both do kickass merges, they both have the same geek features1, they both have big community support (such as Linux, Ruby, and X for Git, or Python, Java, and Google for Mercurial), they're both ridiculously fast. Really, it comes down to personal preference.

So, really, both tools are absolutely awesome. In fact, we're pretty convinced that if you like one, you'll probably like the other--and that if you're using a tool like Subversion, using either would be a tremendous improvement. But, at the end of the day, we had to pick one to base Kiln on, at least for the initial release, and after a lot of looking around, we think that Mercurial's a bit easier-to-use for people new to DVCSes, without sacrificing any of the power of Git.

The important thing, from where we sit, is to help usher in the DVCS revolution. The exact tool people use doesn't really matter so much. We personally have a slight preference for Mercurial, others have a slight preference for Git. Focus on DVCSes vs. the monolithic tools; the rest isn't really that relevant.

1 Those geek features include things like rebasing (git rebase and hg rebase), partial commits (Git index and hg record), history editing (git rebase --interactive and Mercurial's ridiculously powerful MQ facility), signed patches, and so on. Seriously, there's equivalents for basically everything in one tool and the other.