Having used ClearCase, CVS, Subversion, TFS, Git and Mercurial, I would have to say it's because not enough people have tried Mercurial. I have no interest in Git, but I think people like GitHub (or maybe don't know about BitBucket)
Using it in your own ivory tower isn't going to impress anyone for the simple reason that no one sees it. Instead, people look at the broader world of all the interconnected git archives in the linux and web development communities, get excited, pull repos and learn git. There's just no equivalent in the hg community that I see. You guys have walled yourselves off, and it's killing your software.
If most of your work is done with one group of people inside your company and you decide mercurial is a better fit it would seem silly just to go with git because it is popular.
Besides the two are similar enough that someone versed in mercurial should be able to learn enough git to be useful quickly enough should it be required.
And I'm not saying you should choose git because it's better. I'm saying git "won" in the community because it was the choice of people who want to play in the community. Culture matters, and hg's proponents, for whatever reason, are less likely to want to share their stuff.
Do hg people "share less" or are there simply less of them? IIRC github allows commits from hg as well as git.
And of course not everyone (in fact possibly only the minority) is interested in cloning and issuing pull requests on OSS a huge amount of programming happens internally in corporations where everyone will use whichever VCS is mandated.
Subversion was indeed a much better CVS than CVS. And the world almost jumped on it as a standard. But then git appeared. If you were a young person looking at building exciting projects from source, you might never have reason to learn svn. I think that qualifies as "forgotten"
Git just has a directed acyclic graph and pointers to the nodes of it. That's all. End of story.
Mercurial has the concept of a branch, a tag and so on as seemingly separate axiomatic things. It's not as stupid.
I like stupid.
Arguments can be made for both sides, picking a single design decision and saying that that’s obviously better is not going to work. Implementation and (especially in a case like distributed systems) network effects are much stronger than any single isolated design decision.
And of course, if mercurial could give me more features, I'd probably think twice. However, it's practically equivalent to git.
I was comparing git and mercurial, not giving the one true testament to comparison of every possible version control system.
I would argue that in the case of Git it's not about a single design decision. The whole design is very simple and easily understandable. Thus everything can be derived from the design decisions.
The design decisions also have clear rationales.
"Why something is better" and "why something has "won"" are of course different questions that deserve different answers.
Of course, I may also be a terrible teacher.
I find it easy to teach, thanks the concepts being simple and clear. I don't have to transfer a lot of information before people can start reasoning about things themselves and independently finding out more.
I always try to make sure people understand two things:
1) The history tree (==how to read the metro-map that is gitk)
2) Distribution, that you are responsible for syncing with others, not the other way round
Almost everything else I prefer the students at least try to figure out themselves.
Using loaded terms to put down people who use the tool they prefer isn't going to convince anyone that your argument has merit.
[1] Now that you've drawn attention to it, I do indeed wish I'd phrased that differently. But certainly not because I hurt someone's feelings...
Network effect: many many people pick git because everyone else uses it (and that’s a good reason), thus they never try Mercurial, which may or may not be better suited to their use case.
The new BitBucket is awesome, though.
At least that's how I see it.
Also, git is accumulating tooling and integration with other tools much more than hg is, afaict.
Free private repos are great, of course.
> I would have to say it's because not enough people have
> tried Mercurial
code control is a solved problem and people have moved on to do other things...
Mercurial has BitBucket and Bazaar has Launchpad, so they hardly 'loose' to git and GitHub here. There is but one thing that git does better (I'm forced to use git at work) - it's faster, or at least feels faster. Other than that, on the technical side, both Bazaar and Mercurial are I think on par with git and they win hands down in terms of ease of use.
So, yes, I would guess that the cause of git popularity is primarily Linus and then GitHub and then the popularity itself.
If all mercurial is bringing to the table is being a bit more pleasant, I am still going to pass over it for that reason.
[1] dvcs history locally should not be sacred, because rewriting experimental branches is necessary for clarity and to avoid polluting the main repository branches. dvcs history on a central repo can be made sacred with git by disabling non-ff commits and disabling deletes.
DVCS (either mercurial or git) seems to be a much more exotic concept for people unfamiliar with DVCS than MySQL/PostgreSQL is to those only familiar with, say, Oracle RDBMS.
I'm not a DBA though, so maybe I am wildly wrong with that thought.
(Also this comparison maps back to the topic incorrectly, in that I obviously greatly prefer PostgreSQL in the comparison, but I greatly prefer git in the other scenario).
Sourcesafe?
This is a BS argument.
Yes, everybody got it wrong, Git is wrong, SVN is wrong, it's CCs broken model that's correct.
" you need an army of administrators to make it work"
Yes, let's sink an awful amount of money in a half-baked software that needs all kinds of 'helpers' to work properly.
Personally I won't work in a company that uses CC anymore, and it's been only bliss since then.
Sourcesafe is bad, but it's a different kind of bad. And it makes even CC look good.
Mercurial for anything smaller or startup. Love it. The issue with Mercurial is that you'll need to determine how you want to do automated deploy builds, but the code management is great and using BitBucket + Hg I never have trouble seeing which code I'm working in or resolving conflicts. I actually think Mercurial has the second-best visual branching display.
Real big enterprise cannot use TFS without being in a mess with merge. You always have to merge to a parent which require a lot of organisation. Also, it's not the fastest source control when the code base is over few gigs per branches. With over 50 developers/testers (in the same project) we had reach a bottleneck with TFS.