What were the reason for chosing Mercurial as a basis of FogCreek Kiln, a source control management system with tightly integrated code review, and FogBugz integration?
Why Mercurial, and not other (distributed) version control system, like Bazaar, Git or Monotone, or creating own version control system like Fossil (distributed software configuration management, including bug tracking and wiki) did?
What were features that make FogCreek choose Mercurial as Kiln engine?
I can't speak for FogCreek, but I know when I was choosing which DVCS to use many people commented that git does not work well on Windows (unless it's run in cygwin). Since FogBugz is designed to run on either Windows or a Linux systems (from what I understand--I am not a user myself) having an extra layer (cygwin) to run git may have been the determining factor there. I don't know much about Bazaar or Monotone, so I can't offer any feedback there.
I really do not know, but I would venture "better Windows support", Windows being potentially the main platform for most of their client base.
Git is still too much a "unix/linux" product, with a "hopeful" Windows support through mSysGit.
Just read the tone of some of the MSysGitHerald articles, like the ninth one:
For a very long time, msysGit was pushed forward by the gang formed of Hannes, Steffen, Sebastian Schuberth and myself [Johannes Schindelin]. At some stage I got so frustrated that I stopped working on msysGit altogether. The reason is simple: it was no more fun. Way too many people asked for fixes or enhancements, and none of them offered contributions of their own. As I am not a Windows person (being a happy Linux user since 1994), the work on mSysGit was not rewarding enough for me to continue. So I stopped.
But in the meantime, things have changed.
We got contributions by ...
That does not inspire a great deal of confidence when it comes to push forward that tool to your IT boss. I am very happy with Git for a personal usage, and very grateful from the hard work of all mSysGit contributors, but in a big company, I would have a hard time making Git the default DVCS tool adopted by our Windows developers.
Both because of the learning curve, but mainly because the support level is not there yet.
That is only a personal opinion, and if you have a different experience deploying Git successfully, more power to you.
Mercurial being the closest DVCS to Git, and based on portable Python scripts (and not linux/unix-based sh scripts), it may be a pragmatic choice.
Here's an answer from one of the Kiln developers.
Check out the full details here. They explained themselves quite thoroughly.
GIT works quite well with TortoiseGit as integration into Explorer on Windows. Do you know of specifics where this is not satisfactory?
When I looked at DVCS system I like Mercurial because.
Maybe the Kiln developers thought the same...
(All the main DVCS systems are good enough, otherwise other factors would come into play more)
I think the issue of hg vs. git is a red herring, as the OS support issue alone is a major difference. The real question is why hg rather than bzr, as these two are very similar and hg developers themselves consider bzr to be their real competition and vice-versa. Sun conducted an extensive evaluation of both when it came to choosing a DVCS for OpenSolaris and OpenJDK. One would like to know what was the process used for picking hg at FogCreek. All we got so far by way of answers (apart from the OS support issue) are generalities.