It's very sad to see bitbucket dropping mercurial support. Now only Facebook and volunteers are keeping mercurial alive. Sometimes technically better architecture and user interface lose to a non user friendly hard solutions due to inertia of mass adoption.

So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. GitHub successfully marketed git, so git and GitHub are synonymous for most developers. Now majority of open source projects are reliant on a single proprietary solution Github by Microsoft, for managing code and project. Can understand the difficulty of bitbucket, when Python language itself moved out of mercurial due to the same inertia.

Hopefully gitlab can come out with mercurial support to migrate projects using it from bitbucket.

For people who believe in self hosted solution can install Kallithea (https://kallithea-scm.org) or Rhodecode open source edition. Kallithea is used by Unity engine to manage their source code internally with mercurial.

I started my distributed version control journey when SVN was still king of the hill and git and mercurial were both tiny challengers.

I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back.

A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't.

I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.

Git was once fast for my use too. Then I returned to Microsoft to work on building Windows. Even after 2.5 years of improvement,[1] "git is slow" is still one of the most common complaints about the Windows engineering system.

On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.

We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.

[1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...

Definitely sounds like a problem. Do you think an alternative source control solution would handle that situation better? At some point huge with a large number of small files takes its toll.

It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?

I believe the difference is that the Linux kernel itself is not that big a project. Windows is a lot more than just a kernel; it’s more akin to having the source code for an entire Linux distribution in one repo.

You mean like Gentoo (https://github.com/gentoo/gentoo) ? It's not that big either (around 700MB).