41

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?

deft_code
  • 51,579
  • 27
  • 135
  • 215
Jakub Narębski
  • 268,805
  • 58
  • 209
  • 228
  • 6
    You sound like if it is a huge problem for it to be based on Mercurial... What is the problem? – Juliano Nov 09 '09 at 23:19
  • 13
    @juliano: seeing as Jakub has a silver badge for git answers I'd guess it is because they didn't choose git. – deft_code Nov 10 '09 at 00:12
  • 4
    Well... I'd like to know if it was because of some features / characteristic specific to Mercurial (MS Windows support, being written in Python mainly, API and extensions ecosystem, smart HTTP protocol support)... and yes, if it is one of features that Git could improve upon. – Jakub Narębski Nov 10 '09 at 09:28
  • 1
    Git has a lot of traction on github, so there would be a lot of competition. Mercurial is probably the 2nd most popular. – JD Isaacks Jun 28 '12 at 13:02
  • Note: Kiln support Git/GitHub, as I mentioned in my [revises answer](https://stackoverflow.comhttps://stackoverflow.com/a/1704687/6309) – VonC May 27 '18 at 19:05
  • @JakubNarębski maybe it was because Mercurial allows to clone _to_ a remote machine via SSH which - nearly ten years on - Git still hasn't learned, although it should be relatively trivial to implement. – 0xC0000022L Aug 02 '19 at 06:33
  • @0xC0000022L - creating repositories on remote machine, which allows push - and which is equivalent to clone _to_ remote machine - is possible with third party Git repositories management software, like **Gitolite** : via SSH and via HTTPS. – Jakub Narębski Aug 07 '19 at 08:04

6 Answers6

74

Here's an answer from one of the Kiln developers.

  • It provides real branching.
  • It's easy to use.
  • Windows support is very good.
  • It's fast.
  • It's powerful.
  • It's easily extensible.

Check out the full details here. They explained themselves quite thoroughly.

Ben
  • 7,861
  • 1
  • 22
  • 43
deft_code
  • 51,579
  • 27
  • 135
  • 215
  • 19
    +1 for the explanation directly from one of the devs, instead of just speculation. – ThisSuitIsBlackNot Nov 10 '09 at 00:58
  • 2
    the same could be said about Git (apart from windows support), they are both good! – Ian Ringrose Mar 19 '10 at 11:14
  • 18
    the same can not be said about git because of windows support – jk. Mar 19 '10 at 11:32
  • 1
    I love the way that this answer has way more upvotes than the full answer linked to on kiln.stackexhance.com :-) – David Johnstone Mar 26 '10 at 01:25
  • Indeed, all of these points are just as valid (except perhaps for the "windows support" part) for git. In fact, git branching seems more powerful than mercurial. – jsight Jun 15 '10 at 16:39
  • 6
    @jsight I also found Mercurial easier to get into than Git, coming from a Subversion mindset. – Martijn Heemels Nov 25 '10 at 10:56
  • 1
    I also found Mercurial much easier to get into than Git, never having used SVN except to check out ... (mainly ClearCase, some exposure to Accurrev, Visual SourceSafe (yuk) and even RCCS back in uni ...). I'll note that TortoiseGit still is nowhere near as good as TortoiseHg. – Tim Delaney Apr 12 '13 at 21:55
  • 1
    Fixed the link. I don't see anything about branching in there, though, did I miss something? Somebody mentioned git's branches, I think "real branching" refers to permanent long-term branches that are part of history and hard to get rid of, which git doesn't have that I know of (by design). Anyway I'd hoped to see that confirmed in the link but there doesn't seem to be any discussion of that. – Ben Oct 29 '15 at 14:31
  • 3
    Ian: "the same could be said about Git (apart from windows support)" -- Ehh-heh, you've apparently missed the "It's easy to use" part. ;-p Git is the gold standard example of a tool with a user interface designed for its own developers as the target audience. It's like driving your car via CAN-bus adaptors and prototype test equipment loaned from the R&D lab. Extremely powerful, but requires you being in the car industry. – Sz. Jan 24 '16 at 23:20
26

Original answer (Nov. 2009, GitHub has only 1 years, Git only 4)

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.

Update 2018, seven years later: yes, the Windows support for Git is now a reality.

And Microsoft has its entire Windows codebase into one (giant) Git repository: See "The largest Git repo on the planet": 3.5M files, 300GB, 4,000 engineers producing 1,760 daily “lab builds” across 440 branches in addition to thousands of pull request validation builds.
But this is with the addition of GVFS (Git Virtual FileSystem), which allows to dynamically download only the portions you need based on what you use.
This is not yet in Git native, although its integration has begun last Dec. 2017, with the implementation of a narrow/partial cloning.

Kiln advertises Git support as well:

Kiln, our best-in-class DVCS hosting solution, supports Git as well as Mercurial! GitHub is great. FogBugz is great. What could be even better? How about integrating them! FogBugz can be notified by GitHub Web Hooks whenever an incoming changeset comment mentions a case.

0xC0000022L
  • 18,189
  • 7
  • 69
  • 131
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • Git support for Windows existed for quite some time. First one had to build it oneself (and better not forget to clean the 2..3 GB of object files). However, the support for Windows is still half-a^Whalf-hearted, as you will notice the first time you have to deal with a legacy repo which has refs that differ just in letter case. Once Git attempts to unpack these refs (meaning they become file and folder names) you get into trouble. And strictly speaking that's not a Windows problem either. Also, a lack of Windows support is a purely economic rationale ... Git has other issues as well. – 0xC0000022L Aug 02 '19 at 06:48
  • @0xC0000022L I agree with you, in 2009. Now (ten years later), the Windows support is a more concrete reality, since Microsoft employs Johannes Schindelin (dscho), as I mention in https://stackoverflow.com/a/50555740/6309. Since Microsoft has bought GitHub, the economic incentive for supporting Git itself is clearer. – VonC Aug 02 '19 at 07:02
  • I am very skeptical. As far as "porcelain" functionality is concerned I'd be with you. However, "plumbing" in Git is part of the _public interface_, which makes it **exceptionally** hard to fix underlying issues like with the unpacked refs I mentioned in my previous comment. It's one thing to _mention_ how things work under the hood. But with Git one is expected to know it _and_ occasionally be willing to get ones hands dirty there. Sure, not everyone may run into this and perhaps if only one OS is used for development, clients could warn of the (unpacked refs letter case) condition. – 0xC0000022L Aug 02 '19 at 07:08
  • @0xC0000022L True. I see there are still updates done on packed-ref in the upcoming Git 2.23: https://stackoverflow.com/a/41307509/6309. And the tracing is improved (https://stackoverflow.com/a/56094639/6309) – VonC Aug 02 '19 at 07:13
  • Ah, nice. So perhaps these issues will become non-issues in time. Thanks for the pointers. – 0xC0000022L Aug 02 '19 at 07:19
  • @0xC0000022L Speaking of porcelain and plumbing... brace yourself: https://stackoverflow.com/a/57066202/6309 – VonC Aug 02 '19 at 07:30
9

When I looked at DVCS system I like Mercurial because.

  • The Mercurial developers seems to care about Microsoft Windows users.
  • The Mercurial developers do not thinks of Microsoft Windows users as being Unix users that are forced to use Windows.
  • Unlike a lot of open source developers, the Mercurial developers don't seem to hate Microsoft for making money.

Maybe the Kiln developers thought the same...
(All the main DVCS systems are good enough, otherwise other factors would come into play more)

Ian Ringrose
  • 49,271
  • 50
  • 203
  • 302
  • truth is you have to be able to afford being an open source developer. Either because you still live with your parents or because you live in your mom's basement as a (technically) grownup or because you earn your money some other way (including writing proprietary software) and in all these cases you still have to be able to afford the time to develop FLOSS. It can be very rewarding, but also very frustrating. I don't think the generalization that FLOSS developers hate Microsoft isn't true. I for one have developed FLOSS specifically _for Windows_. – 0xC0000022L Aug 02 '19 at 06:58
  • 1
    @0xC0000022L look at the date I wrote the answer – Ian Ringrose Aug 02 '19 at 15:19
  • what about it? I could have written that comment just the same (except I just noticed I have a double negation in it, which was _not_ intended) ten years ago. Because even then I was developing FLOSS software for WIndows in my spare time, yet working for a vendor of proprietary software (for Windows, Linux, Solaris, AIX, ...). – 0xC0000022L Aug 03 '19 at 19:48
7

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.

Stephen Newell
  • 6,076
  • 1
  • 21
  • 23
4

So now they add also git:

One of the biggest new features is Kiln Harmony, which lets you operate on Kiln repositories using either Git or Mercurial. So you can push changes to a Kiln repo using Git and then pull them using Mercurial. This means that you never have to decide whether you want to use Git or Mercurial.

Alexan
  • 6,893
  • 13
  • 69
  • 89
  • I think this very feature might get me move over there from GitHub. – Sz. Jan 24 '16 at 23:23
  • @Sz. I believe I read somewhere _that_ exact feature was discontinued by now. See [here](https://stackoverflow.com/q/19543512) for some pointers. – 0xC0000022L Aug 02 '19 at 06:50
4

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.

olefevre
  • 3,918
  • 3
  • 19
  • 22
  • Four years on, Bazaar seems to exist as a shadow of its former self. While Mercurial evolves, Bazaar development seems to have stopped, although a friendly fork exists in [Breezy](https://launchpad.net/brz) [and that is very much still alive]. – 0xC0000022L Aug 02 '19 at 06:54