Comment by manithree
1 day ago
LOL. In 2007, I did a side-by-side comparison of SVN, Mercurial and git with my codebase at work (~700k LOC). I know hg got faster eventually, but I still can't believe people say "hg should have won the DVCS war" with a straight face. It was orders of magnitude slower in my tests. Like, 20 minutes to commit large xml files (yeah, I know, but that's where we were). Not just a few ms slower, unbearably slow for several things.
I liked its features better, but chose git, and that was the correct decision.
This isn't an apology or a deflection, but different VCSes strike different trade-offs in terms of speed per workload. The mercurial storage model is comparable to video encoding in that it has a somewhat equivalent of "key frames" and alternates differential and full revisions¹. This makes workloads like bisecting or jumping to long-distance commits more efficient, at the expense of the time to create new commits.
For your use-case, mercurial has had a `largefiles`² extension for a very long time (long before git-lfs).
> I liked its features better, but chose git, and that was the correct decision.
Anyhow, my personal story with git is that I bought into the hype and social effects without really challenging my assumptions ("it must be the best, everyone says so"), until I got very fed-up with its obnoxious UI, and someone on IRC told me "ehh, give hg a shot". Nowadays, I mostly interact with git repos through hg-git and jj.
¹: https://www.kernel.org/doc/ols/2006/ols2006v2-pages-91-98.pd...
²: https://wiki.mercurial-scm.org/LargefilesExtension