18 ms·

I kind of killed Mercurial at Mozilla

285 points by sylvestre 3y ago

galkk 3y ago
Interesting, given that Google and Facebook [2], at least, eventually moved to have their repositories offered via Mercurial interface, instead of git. I also would expect that Github eventually will also offer mercurial repos. p.s. And let's not talk about abomination that is GitLFS (starting from the fact that it requires separate subcommand). [2] https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/ https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...
- numbsafari 3y ago
  That’s 2014 vintage. Is it still true?
  - slimginz 3y ago
    Yup! In fact Meta’s implementation is open sourced as Sapling SCM and includes both Mercurial and Git support[1]. Internally the main repository use Mercurial although I believe a few legacy projects still use git. [1] https://sapling-scm.com/ https://sapling-scm.com/
    - explodingcamera 3y ago
      From the documentation, it seems like there is 0 mercurial support. It's its own separate version control system that diverged years ago. You can either use the sapling scm client or git.
      - slimginz 3y ago
        Oh I didn’t realize. Internally we use `hg` commands for everything so I guess it’s just the internal version that supports mercurial
  - pineapple_sauce 3y ago
    Meta uses https://github.com/facebook/sapling https://github.com/facebook/sapling see: https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engineering.fb.com/2022/11/15/open-source/sapling-so... It’s an extension from Mercurial as the blog post states.
- lutoma 3y ago
  > I also would expect that Github eventually will also offer mercurial repos. How come? That seems highly unlikely to me, especially when you consider that one of their larger competitors (Bitbucket) had Mercurial support for a long time and then removed it.
  - mrighele 3y ago
    In fact Bitbucket started as a Mercurial hosting service, then added Git support, then dropped Mercurial. From when they dropped Mercurial in 2020 [1]: "Yesterday marked an end of an era for Mercurial users, as Bitbucket announced to no longer support Mercurial repositories after May 2020. Bitbucket, owned by Atlassian, is a web-based version control repository hosting service, for source code and development projects. It has used Mercurial since the beginning in 2008 and then Git since October 2011." [1] https://hub.packtpub.com/bitbucket-to-no-longer-support-mercurial-users-must-migrate-to-git-by-may-2020/ https://hub.packtpub.com/bitbucket-to-no-longer-support-merc...
  - Blackthorn 3y ago
    That change was so dumb. Mercurial support was the bit that put them as something different from github. Once they didn't have it anymore, why would anyone use them at all?
    - the_mitsuhiko 3y ago
      I'm sure they knew what they did. They probably primarily had git users on the service, and the motivation to use Bitbucket is most likely because you already pay for other Atlassian products.
    - jeremyjh 3y ago
      So since you are knowledgeable about the fact that this decision was "dumb", you must also know approximately what proportion of their users were dependent on hg for their workflow ? My priors would put it at less - likely far less - than 1%. But please share your knowledge.
      - 3y ago
- wmf 3y ago
  FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engineering.fb.com/2022/11/15/open-source/sapling-so... Mercurial is over.
  - LAC-Tech 3y ago
    > Mercurial is over. I mean to be fair so is Firefox
    - nine_k 3y ago
      Wait until Google starts to suppress ad blockers for real in a few months.
      - LAC-Tech 3y ago
        People will switch to brave, not Firefox.
  - 1letterunixname 3y ago
    Meta's fork/rewrite of hg, Sapling hasn't gone anywhere yet because it needs EdenFS and Mononoke that aren't yet/maybe never FOSS. It's only called hg internally because of legacy reasons but it's completely different. Microsoft hired a git maintainer to improve large repo performance and so it's better than it was.
    - Shish2k 3y ago
      I’ve been using the sapling CLI as my frontend with github as my backend and finding it quite delightful - all the UX niceness from mercurial (and then some), while still being totally compatible with the rest of my team :)
    - aseipp 3y ago
      Sapling can use Mononoke, but it can also use Git repositories as the underlying storage layer with no server at all, and it does so by default in the OSS build. You can use it just fine with GitHub today, but there are rough edges. My understanding is that the work to support OSS builds of Mononoke+EdenFS is happening, but there's no exact timeline right now because (from what I can tell) they basically have to abstract out and write new production storage components for the metadata/object layer, as they can't use their internal ones, obviously.
- billllll 3y ago
  Bitbucket dropped Mercurial support in 2020: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket https://bitbucket.org/blog/sunsetting-mercurial-support-in-b... I just don't think there is good RoI for implementing Mercurial support. It really isn't about the interface (which I think most people agree hg is better than git). It's just the network effect: most projects use git so everybody learns git and they don't want to learn another tool even if it's better in some ways. At the end of the day, once you pay a higher upfront cost to learn the ~5 git invocations you need, your daily productivity between using git and hg is probably the same. Google and Facebook is different: they have a unique use-case and scale, and massive internal tooling teams supporting their use-cases. Also, as an employee, you're probably more open to different VCS systems because if you learn hg at Facebook, you're learning it on company time whereas if you learn for an open source project, you're learning it on your time.
  - dehrmann 3y ago
    > It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).
    - acdha 3y ago
      Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool. I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time. The marginal returns on productivity weren’t worth switching in most cases so it tended to come down to Git being so much faster and, as network effects kicked in, easier to host.
- astrange 3y ago
  I knew the guy who wanted Google Code to be Mercurial based; he pretty much just did it because he liked Python and therefore thought anything written in Python was good.
  - barrkel 3y ago
    hg split is a lot more tedious to do in git.
- aseipp 3y ago
  Google currently uses a fork of Mercurial as the frontend to Piper, but there is work to replace it wholesale, eventually: https://github.com/martinvonz/jj https://github.com/martinvonz/jj (As a disclosure, I'm involved with and contribute to jj, but I don't work for or speak for Google in any way; the above statement is public knowledge.)
  - culi 3y ago
    Any comments about what it does better than git and mercurial?
    - aseipp 3y ago
      I completely rewrote the README recently to be more "user friendly"; does it address some of your question? I'm not trying to be snarky, I'm genuinely interested in if the README is now tantalizing enough to make you interested: https://github.com/martinvonz/jj?tab=readme-ov-file#introduction https://github.com/martinvonz/jj?tab=readme-ov-file#introduc... But in short, it has a better UX than Git by a mile while remaining interoperable at the storage level, so you can use GitHub; it has many of the niceties of Mercurial's UX like revsets, no staging area, and a templating language for log output. Conflict resolution and rebasing is clean, easy, and nearly automatic. It has features neither support, like a real undo command and "operation log"[1]. The UX is smaller and conceptually cleaner; fewer "verbs" that operate on less "nouns", so many things are more regular. It is available as an API (Rust crates) so you can extend it naturally to handle your own workflow, without monkey-patching things. You could even use Mercurial itself as a storage backend, or a custom, centralized server like Google does. Most importantly though, its internal "automatic snapshot model" design is quite elegant and makes the design and internals very clear. And storage system is completely independent and abstracted from this, and many of the other algorithmic details (Git sort of intertwines the data model, the algorithms, and the UX in various ways.) Features like hg changeset evolution, git rerere, and rebase --update-refs are all obsoleted and naturally handled by this design, among other things. Martin, the lead developer, also had a talk at Git Merge 2022 that covers many of the fundamentals. They're all still the same but we're evolving many things rapidly: https://www.youtube.com/watch?v=bx_LGilOuE4 https://www.youtube.com/watch?v=bx_LGilOuE4 [1] Yes I know about the reflog, no it is not equivalent! It only tracks changes made to visible references ("ref" "log") while jj's oplog actually tracks commands invoked, and lets you completely undo individual things in the blink of an eye, or rewind if you wish.
- barrkel 3y ago
  https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... is a public reference for Mercurial front-ending Piper.
- kevin_thibedeau 3y ago
  Google anointed Mercurial before Git. Google Code was Mercurial and Subversion only until near the end of its days.
  - cmrdporcupine 3y ago
    The reason is the same as for why "fig" was done internally -- git is a DVCS that runs over a filesystem, while Mercurial has an actual protocol, so the storage layer can be plugged out. Presumably for Google Code it was some appengine or bigtable type backend. For fig, I believe it was, somehow, piper.
- cmrdporcupine 3y ago
  My understanding with the Mercurial stuff at Google is it was done that way because Mercurial defines a wire protocol, while Git does not (it expects a filesystem). So when fig was put together, they simply couldn't use git for the intended workflow, because it needed to be able to front-facade the existing CitC/Piper repository. Prior to that, we used to use 'git5' which was kind of git bolted on in front of Piper, and it worked, but it was a little wonky with explicit import and export steps. I tried to use fig a little before I left, and I can't say I was entirely blown away. I used to like Mercurial a decade and a half ago, and learned it before git... but it felt very foreign to me now.
- cookiengineer 3y ago
  I came here to mention that mercurial handles large binaries very well, wheras git LFS is a fustercluck of a workflow. It's like submodules, where people 99% of the time have to add the --init --recursive flags anyways, and yet nobody cares to optimize the workflow. I wish git had better submodules, and better binary asset folders that could be linked and cloned/fetched/pulled/pushed without having to have a complete checkout of the whole repository with all its history. Oh, and automatic pruning would be nice because my git servers constantly run out of HDD space when I don't do git gc regularly, which oftentimes is broken in itself already.
Sparkyte 3y ago
Software unmaintained kills itself. I wouldn't feel all too bad if you found a different solution that fits your demand. To say one shoe fits all is silly.
zabzonk 3y ago
i kind of wonder why there has never been an "hghub", given that i've always liked hg rather than git. but i guess it is the torvalds connection?
- nickcox 3y ago
  There was bitbucket.
- rstarast 3y ago
  I want to say bitbucket started out as this, at least my first repos there were hg.
  - zabzonk 3y ago
    yep, that's what i used to use, but it was shut down and i don't really know why - would it have cost so much to have kept it open? dunno - i really know nothing about the economics of keeping such things going.
    - mrweasel 3y ago
      I don't recall if this was before or after Atlassian bought Bitbucket, but they had a number of issues keeping the site running. There where so many outages, the site was frequently slow to the point of being useless. I know because we where a paying customer. I suspect that they had to few paying customers and because the service was so prone to outages they had acquired a bad reputation so they couldn't attract new customers. Maybe if Bitbucket had been a Silicon Valley company they would have had access to funding, allowing them to grow in the same way Github did. When it worked it was fine, but in the end you just got way better service and performance on Github. The current iteration of Bitbucket isn't even Bitbucket, it's Stash. That works really well to, if you like Atlassian tools.
- bluGill 3y ago
  Because you never wrote it. The curse of open source. By the time github came about, git already had a lot more mindshare than hg. While hg wasn't yet clearly an also ran, it was clearly the less popular solution, and many open source tools started supporting git but either not supporting hg, or if they did it was an afterthought and often the maintainers broke something hg without noticing and then releasing with broken hg support.
Yoric 3y ago
Snitched upon by his colleague, too! (hi glandium, sylvestre)
- sylvestre 3y ago
  Coucou ;)
  - lizzard 3y ago
    Joining the party, that was a trip down memory lane!
    - dblohm7 3y ago
      I might as well jump in on this, too...
      - tarasglek 3y ago
        nice
        glandium 3y ago
        Is this the thread where Mozillians assemble?
        dblohm7 3y ago
        Into that Quantum-bot exosuit thingy?
liveoneggs 3y ago
Mercurial has a quintessential "Rewrite it in rust!" page: https://wiki.mercurial-scm.org/OxidationPlan https://wiki.mercurial-scm.org/OxidationPlan
- goku12 3y ago
  The last update is from 2018. Did they give up?
  - liveoneggs 3y ago
    the release notes imply that they are still at it
  - oblio 3y ago
    Most likely. Well, it's open source, so it's "dormant".
danking00 3y ago
I've heard this point of view many times, but cannot find an extensive explanation of it. Could anyone elaborate on the issue with the GitHub review UI/UX? > I hate the GitHub review UI with a passion. At least, right now, GitHub PRs are not a viable option for Mozilla [...] the more general shortcomings in the review UI.
- steveklabnik 3y ago
  I know people who express similar feelings. Usually it is shorthand for "I would prefer stacked diffs" or similar. Two blog posts I've seen people point at: * https://mitchellh.com/writing/github-changesets https://mitchellh.com/writing/github-changesets * https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/ https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/
  - anyonecancode 3y ago
    From the second article, a minor point but possibly helpful to other here, he contrasts doing everything in the terminal with stacked commits vs going to the Github UI. If people aren't aware, Github offers a cli tool[1]. I've been using it for a few months now and am finding it does make me more productive -- it's nice to be able to open up a PR directly from my terminal. I do still use the GH UI for a lot of things, but I'll often at least start in the terminal, and it also makes the transition from terminal to browser easy as many commands support the `--web` flag open up the right page for you (eg `gh repo view --web`). [1] https://cli.github.com/ https://cli.github.com/
    - lima 3y ago
      The CLI doesn't help with stacked commits, though. There's tools like spr[1] but none of them are anywhere as pleasant to use as Gerrit (or Phabricator, I guess). [1]: https://github.com/ejoffe/spr https://github.com/ejoffe/spr
      - anyonecancode 3y ago
CorrectHorseBat 3y ago
Linux kernel development never used cvs, I believe Linus thought it gives people brain damage and did just send around patches and tarballs
- glandium 3y ago
  Linus never used CVS, but there was a CVS server and the community was using it. https://flosshub.org/sites/flosshub.org/files/127-131.pdf https://flosshub.org/sites/flosshub.org/files/127-131.pdf
  - bananapub 3y ago
    parts of the community, if I recall correctly, and to be clear to everyone else since I'm sure you know this: 1. linus didn't use version control at all, he just got patches emailed to him, then every now and then he'd publish a tarball and incremental patches (e.g. a 2.4.11-rc2 patch on top of 2.4.11-rc1) - the world had no visibility into his tree's development aside from the tarballs and inter-version patches he sent out 2. and because of that, no one else used version control for submitting changes, they just sent patches to lkml 3. there was some use of CVS for some ports / subsystems, but again, it was used to generate patches to email to linus 4. people built lots of tools around this work flow, like `patchwork` and horrible shell scripts
- ranting-moth 3y ago
  Of course you can run your project like Linux. Your first requirement is to employ Linus Torvalds as a project manager.
interroboink 3y ago
I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused with "named branches"). There was no direct equivalent to git's branches. Eventually, Mercurial got 'bookmarks' which basically closes that gap, but that only became a core feature in 2011, well after these Mozilla repos were established. ---- Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (:
- glandium 3y ago
  Author here. > my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). Fair point. I came up with the title first. Then as the content grew large and diluted the essence of the title, I reconsidered, but ended up sticking to it as a shameless clickbait. > Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused with "named branches"). That still leaves the question "why topic branches rather than named branches?". For the needs of the rapid release process, named branches could have been used, but weren't. I haven't tried to contact the people involved at the time to have a definite answer. It's not /that/ important, and I'm not /that/ curious.
  - lynguist 3y ago
    What a beautiful post it has become nevertheless rivaling the long reads of the New Yorker and the like. I originally wanted to go to sleep but the writing was too captivating to put down, and every paragraph was motivated, and it wasn’t stretched. It was the length it needed to be.
  - kbrosnan 3y ago
    Tracking down preed, JST, joduin, bsmedberg, etc might turn up stories. Some of it is captured by preed in https://soberbuildengineer.com/blog/2006/11/version-control-system-shootout-redux/index.html https://soberbuildengineer.com/blog/2006/11/version-control-... and announcing hg in https://soberbuildengineer.com/blog/2007/04/version-control-system-shootout-redux-redux/index.html https://soberbuildengineer.com/blog/2007/04/version-control-... JST post on bzr vs hg perf, https://web.archive.org/web/20070219012211/http://weblogs.mozillazine.org/jst/archives/2007/02/more_on_distributed_vcs_perfor.html https://web.archive.org/web/20070219012211/http://weblogs.mo...
oktwtf 3y ago
My only experience with Mercurial was in game development. What’s used these days in arenas where large file versioning is needed? I think the ultimate answer is maintaining an asset stack containing files that allow for inherit diff chunks or however that might be described.
- swozey 3y ago
  I've only used SVN and Git and I'm almost 20 years into my career at this point so I know nothing of these others but my game dev friends all use Perforce. I couldn't tell you a single thing about it though.
- kaelinl 3y ago
  Yeah, my understanding is that it's pretty universally Perforce in game dev. For them it's the large file versioning. I work at an ASIC firm and we similarly use Perforce; to some extent for the large file versioning, and to some extent for other general scale benefits.
- WorldMaker 3y ago
  Git LFS is supported by most hosts these days. It's "fine".
- johnwalkr 3y ago
  There's gitLFS but it requires some discipline to use.
mjhay 3y ago
Reading that article unlocked some traumatic memories of Bazaar/"bzr".
- glandium 3y ago
  Writing the article unlocked some traumatic memories of arch.
- bombcar 3y ago
  I liked bzr because it had simple to understand “versions” I could abuse to use like a single source of truth. Git requires manually applying tags to imitate it.
hexo 3y ago
Thank you, mercurial was obstacle (for me) all the time. Thanks for killing it.
sys_64738 3y ago
Solaris source control moved to Mercurial so if you want to know if it scales then the answer is yes. I miss SCCS.
- yjftsjthsd-h 3y ago
  Didn't Sun have Gatekeepers carefully controlling what commits were made to any given gate, thereby ensuring that the actual source control would never be the limiting factor in scaling things out? (Don't get me wrong, I love mercurial, I just don't think this particular example demonstrates much because it always sounded like they'd sidestepped the issue.)
  - sys_64738 3y ago
    Yes, any putback to ON required an advocate to vouch for your change. Basically a neck to wring when things go wrong. You generally had me chance so don’t F. Up.
DominoTree 3y ago
Thank you.
wsc981 3y ago
I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest. I used Mercurial in the past for a bit, and it was fine. But for me it doesn't seem to have any huge advantages over git, if any. And after so many years of experience using git, I know what workflows work well, how to resolve merge conflicts, how to revert to an old commit if something really gets messed up, etcetera. I don't see any other DVCS really being able to replace git in the short run and I wouldn't be surprised if git will stay number 1 for the following decennia, as in my opinion it's really great software. A DVCS really has to provide substantial benefits over git in order to replace git as the number 1 DVCS.
- czscout 3y ago
  The sheer functionality of git is amazing. The number of times I have encountered a new situation and used a previously unknown (to me) feature, or (equally as impressive) been able to harness the flexibility of the software to wrangle some strange edge case are innumerable. All that while also being lightning fast.
- cmrdporcupine 3y ago
  Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names. People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way. That and there's so many ways to use it. Mercurial had the advantage of having a much more consistent UX. Though these days I'm sure I'd struggle with it, because I'm so used to git. Mercurial was never trying to "replace" git. All of these guys came out at the same time. Git got headspace because Linux used it and GitHub was a "cool" Ruby on Rails site, run by cool web 2.0 kids, same era as the rise of Twitter, etc. (And also down all the time, just like Twitter).
  - bigstrat2003 3y ago
    Exactly this. To be perfectly honest, the git CLI is so bad that I would take pretty much anything over git. I would prefer SVN over git, despite that product being older and with less functionality, just because it's at least easy to use. I learned and use git because that's just how the industry has moved, and I'm pragmatic enough to just roll with it. But good Lord, the UI is a case study in "programmers shouldn't be allowed to design UIs".
riffraff 3y ago
As someone who was using darcs in that era: it wasn't just slow in the sense of "it takes 10 seconds rather than 1". It was possible to get into situations where it would take hours to merge changes. Apart from that it was the best developer experience I've had with a VCS.
BrenBarn 3y ago
I hate to see more and more people switching from Mercurial to Git. The way to overcome the "network effects" is exactly for large projects like Mozilla to stand tall and say clearly that they are going to use Mercurial because it is better and git is worse. Of course, I shouldn't really expect such from Mozilla given all the other dubious actions they've taken over time.
- zarzavat 3y ago
  Git won a long long time ago. Most people’s first VCS is now git. Mercurial is a lot better than SVN so it was able to pick up users back when SVN was dominant, but it’s not really better or worse than git it’s just down to taste. When you consider the network effects and switching costs it’s hard to convince anyone that mercurial is worth learning.
  - iggldiggl 3y ago
    I initially picked up Git because that was the cool/recommended thing to do. Then I started contributing to Firefox and at that time the story for using Git with Firefox's Mercurial repository was much more cumbersome, so I gave up and started using Mercurial instead. Over time, Mercurial has grown on me and these days I actually prefer it over Git.
- jillesvangurp 3y ago
  You'd need some arguments for the assertion that mercurial is better. I think Mozilla is switching because of years of failing to come up with good arguments. And it looks like they gave it a lot of thought. That and an increasing dependence on git internally to the point where people were spending non trivial amounts of time engineering around mercurial and coming up with all sorts of hacks to enable git usage. At least, that's what the article suggests actually happened. You'll never get consensus on X being better than Y in the tech world. There are always going to be people that insist Y is better than X. And more power to them. But you have to be realistic. There is a lot of stuff that just never gets a lot of traction. Mercurial is one of those things. It's like betamax vs. vhs. Initially it looked promising and then Github happened and the rest is history. The whole industry now runs on Git and Mercurial sort of flat lined in terms of growth after Github started hosting essentially the entirety of the OSS world (with few but notable exceptions of course). At this point it's a hard sell for new projects and some of the larger remaining users are switching away or are considering it.
wirrbel 3y ago
What a shame. I came in contact with version control systems in the following order CVS (also a bit of a weird episode using RCS), Subversion, git, then mercurial I have loved git and still do. But nowadays I use mercurial for my pet projects. There is no denying that git "won", mercurial would have been a worthy alternative.
xvilka 3y ago
I hope one day Pijul[1] will become more common, as the more advanced alternative to git. [1] https://pijul.org/ https://pijul.org/
self_awareness 3y ago
I kind of like Fossil nowadays, although I'm not entirely on par with their philosophy of not squashing branches. But the "all-in-one" aspect, together with "one binary" is pretty nice.
grey_earthling 3y ago
Switching to Git makes sense, but choosing GitHub is diametrically opposed to what Mozilla claim their principles are — specifically principle 6 of the Mozilla Manifesto: “The effectiveness of the internet as a public resource depends upon interoperability (protocols, data formats, content), innovation and decentralised participation worldwide.” => https://www.mozilla.org/en-GB/about/manifesto/ https://www.mozilla.org/en-GB/about/manifesto/ In future it won't be possible to contribute to Firefox without a Microsoft account. If Microsoft decide to close your account (which they're entitled to do — they own the website), you can't participate. Mozilla were one of the few hold-outs against this particular attempted monopoly. Again, Mozilla makes a short-termist decision that makes sense for a Silicon Valley lifestyle brand, but makes no sense for an independent mission-driven public-service community project. They're an untrustworthy upstream.
- seanw444 3y ago
  > They're an untrustworthy upstream. All I needed to come to this conclusion was the abandonment of interesting (and necessary) projects like Servo, and the continual increase of superiors' salaries.
- jamienicol 3y ago
  > In future it won't be possible to contribute to Firefox without a Microsoft account What makes you think that?
  - grey_earthling 3y ago
    If I understand correctly, they're moving development to GitHub, and not hosting their own git servers. So you'd need a GitHub (Microsoft) account to merge a change to the code.
BlackFingolfin 3y ago
A bit off-topic, but: I am somewhat confused by the claim “Subversion was created by Jim Blandy”. I was around back then, and the names I think of when it comes to “who created Subversion” are Ken Fogel, Ben Collins-Sussman, and Mike Pilato. And certainly many other people, including Jim Blandy. My recollection seems to be supported by e.g. https://news.apache.org/foundation/entry/the-apache-software-foundation-announces58 https://news.apache.org/foundation/entry/the-apache-software... and also by looking at the early subversion repository history and mailing list posts. But I was only a bystander (and early adopter), so maybe something went on "behind the scenes" that warrants this attribution? Or maybe it is a just a bit careless and was meant to be more like "... he was one of the creators", which one probably could justify. Coincidentally, I just checked the Wikipedia page for Subversion and was surprised that there is basically nothing on the history of Subversion and who created it, which I find sad.

285 points by sylvestre 3y ago

Interesting, given that Google and Facebook [2], at least, eventually moved to have their repositories offered via Mercurial interface, instead of git. I also would expect that Github eventually will also offer mercurial repos. p.s. And let's not talk about abomination that is GitLFS (starting from the fact that it requires separate subcommand). [2] https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/ https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...

numbsafari 3y ago
That’s 2014 vintage. Is it still true?
- slimginz 3y ago
  Yup! In fact Meta’s implementation is open sourced as Sapling SCM and includes both Mercurial and Git support[1]. Internally the main repository use Mercurial although I believe a few legacy projects still use git. [1] https://sapling-scm.com/ https://sapling-scm.com/
  - explodingcamera 3y ago
    From the documentation, it seems like there is 0 mercurial support. It's its own separate version control system that diverged years ago. You can either use the sapling scm client or git.
    - slimginz 3y ago
      Oh I didn’t realize. Internally we use `hg` commands for everything so I guess it’s just the internal version that supports mercurial
- pineapple_sauce 3y ago
  Meta uses https://github.com/facebook/sapling https://github.com/facebook/sapling see: https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engineering.fb.com/2022/11/15/open-source/sapling-so... It’s an extension from Mercurial as the blog post states.
lutoma 3y ago
> I also would expect that Github eventually will also offer mercurial repos. How come? That seems highly unlikely to me, especially when you consider that one of their larger competitors (Bitbucket) had Mercurial support for a long time and then removed it.
- mrighele 3y ago
  In fact Bitbucket started as a Mercurial hosting service, then added Git support, then dropped Mercurial. From when they dropped Mercurial in 2020 [1]: "Yesterday marked an end of an era for Mercurial users, as Bitbucket announced to no longer support Mercurial repositories after May 2020. Bitbucket, owned by Atlassian, is a web-based version control repository hosting service, for source code and development projects. It has used Mercurial since the beginning in 2008 and then Git since October 2011." [1] https://hub.packtpub.com/bitbucket-to-no-longer-support-mercurial-users-must-migrate-to-git-by-may-2020/ https://hub.packtpub.com/bitbucket-to-no-longer-support-merc...
- Blackthorn 3y ago
  That change was so dumb. Mercurial support was the bit that put them as something different from github. Once they didn't have it anymore, why would anyone use them at all?
  - the_mitsuhiko 3y ago
    I'm sure they knew what they did. They probably primarily had git users on the service, and the motivation to use Bitbucket is most likely because you already pay for other Atlassian products.
  - jeremyjh 3y ago
    So since you are knowledgeable about the fact that this decision was "dumb", you must also know approximately what proportion of their users were dependent on hg for their workflow ? My priors would put it at less - likely far less - than 1%. But please share your knowledge.
    - 3y ago
wmf 3y ago
FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engineering.fb.com/2022/11/15/open-source/sapling-so... Mercurial is over.
- LAC-Tech 3y ago
  > Mercurial is over. I mean to be fair so is Firefox
  - nine_k 3y ago
    Wait until Google starts to suppress ad blockers for real in a few months.
    - LAC-Tech 3y ago
      People will switch to brave, not Firefox.
- 1letterunixname 3y ago
  Meta's fork/rewrite of hg, Sapling hasn't gone anywhere yet because it needs EdenFS and Mononoke that aren't yet/maybe never FOSS. It's only called hg internally because of legacy reasons but it's completely different. Microsoft hired a git maintainer to improve large repo performance and so it's better than it was.
  - Shish2k 3y ago
    I’ve been using the sapling CLI as my frontend with github as my backend and finding it quite delightful - all the UX niceness from mercurial (and then some), while still being totally compatible with the rest of my team :)
  - aseipp 3y ago
    Sapling can use Mononoke, but it can also use Git repositories as the underlying storage layer with no server at all, and it does so by default in the OSS build. You can use it just fine with GitHub today, but there are rough edges. My understanding is that the work to support OSS builds of Mononoke+EdenFS is happening, but there's no exact timeline right now because (from what I can tell) they basically have to abstract out and write new production storage components for the metadata/object layer, as they can't use their internal ones, obviously.
billllll 3y ago
Bitbucket dropped Mercurial support in 2020: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket https://bitbucket.org/blog/sunsetting-mercurial-support-in-b... I just don't think there is good RoI for implementing Mercurial support. It really isn't about the interface (which I think most people agree hg is better than git). It's just the network effect: most projects use git so everybody learns git and they don't want to learn another tool even if it's better in some ways. At the end of the day, once you pay a higher upfront cost to learn the ~5 git invocations you need, your daily productivity between using git and hg is probably the same. Google and Facebook is different: they have a unique use-case and scale, and massive internal tooling teams supporting their use-cases. Also, as an employee, you're probably more open to different VCS systems because if you learn hg at Facebook, you're learning it on company time whereas if you learn for an open source project, you're learning it on your time.
- dehrmann 3y ago
  > It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).
  - acdha 3y ago
    Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool. I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time. The marginal returns on productivity weren’t worth switching in most cases so it tended to come down to Git being so much faster and, as network effects kicked in, easier to host.
astrange 3y ago
I knew the guy who wanted Google Code to be Mercurial based; he pretty much just did it because he liked Python and therefore thought anything written in Python was good.
- barrkel 3y ago
  hg split is a lot more tedious to do in git.
aseipp 3y ago
Google currently uses a fork of Mercurial as the frontend to Piper, but there is work to replace it wholesale, eventually: https://github.com/martinvonz/jj https://github.com/martinvonz/jj (As a disclosure, I'm involved with and contribute to jj, but I don't work for or speak for Google in any way; the above statement is public knowledge.)
- culi 3y ago
  Any comments about what it does better than git and mercurial?
  - aseipp 3y ago
    I completely rewrote the README recently to be more "user friendly"; does it address some of your question? I'm not trying to be snarky, I'm genuinely interested in if the README is now tantalizing enough to make you interested: https://github.com/martinvonz/jj?tab=readme-ov-file#introduction https://github.com/martinvonz/jj?tab=readme-ov-file#introduc... But in short, it has a better UX than Git by a mile while remaining interoperable at the storage level, so you can use GitHub; it has many of the niceties of Mercurial's UX like revsets, no staging area, and a templating language for log output. Conflict resolution and rebasing is clean, easy, and nearly automatic. It has features neither support, like a real undo command and "operation log"[1]. The UX is smaller and conceptually cleaner; fewer "verbs" that operate on less "nouns", so many things are more regular. It is available as an API (Rust crates) so you can extend it naturally to handle your own workflow, without monkey-patching things. You could even use Mercurial itself as a storage backend, or a custom, centralized server like Google does. Most importantly though, its internal "automatic snapshot model" design is quite elegant and makes the design and internals very clear. And storage system is completely independent and abstracted from this, and many of the other algorithmic details (Git sort of intertwines the data model, the algorithms, and the UX in various ways.) Features like hg changeset evolution, git rerere, and rebase --update-refs are all obsoleted and naturally handled by this design, among other things. Martin, the lead developer, also had a talk at Git Merge 2022 that covers many of the fundamentals. They're all still the same but we're evolving many things rapidly: https://www.youtube.com/watch?v=bx_LGilOuE4 https://www.youtube.com/watch?v=bx_LGilOuE4 [1] Yes I know about the reflog, no it is not equivalent! It only tracks changes made to visible references ("ref" "log") while jj's oplog actually tracks commands invoked, and lets you completely undo individual things in the blink of an eye, or rewind if you wish.
barrkel 3y ago
https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... is a public reference for Mercurial front-ending Piper.
kevin_thibedeau 3y ago
Google anointed Mercurial before Git. Google Code was Mercurial and Subversion only until near the end of its days.
- cmrdporcupine 3y ago
  The reason is the same as for why "fig" was done internally -- git is a DVCS that runs over a filesystem, while Mercurial has an actual protocol, so the storage layer can be plugged out. Presumably for Google Code it was some appengine or bigtable type backend. For fig, I believe it was, somehow, piper.
cmrdporcupine 3y ago
My understanding with the Mercurial stuff at Google is it was done that way because Mercurial defines a wire protocol, while Git does not (it expects a filesystem). So when fig was put together, they simply couldn't use git for the intended workflow, because it needed to be able to front-facade the existing CitC/Piper repository. Prior to that, we used to use 'git5' which was kind of git bolted on in front of Piper, and it worked, but it was a little wonky with explicit import and export steps. I tried to use fig a little before I left, and I can't say I was entirely blown away. I used to like Mercurial a decade and a half ago, and learned it before git... but it felt very foreign to me now.
cookiengineer 3y ago
I came here to mention that mercurial handles large binaries very well, wheras git LFS is a fustercluck of a workflow. It's like submodules, where people 99% of the time have to add the --init --recursive flags anyways, and yet nobody cares to optimize the workflow. I wish git had better submodules, and better binary asset folders that could be linked and cloned/fetched/pulled/pushed without having to have a complete checkout of the whole repository with all its history. Oh, and automatic pruning would be nice because my git servers constantly run out of HDD space when I don't do git gc regularly, which oftentimes is broken in itself already.

Sparkyte 3y ago

Software unmaintained kills itself. I wouldn't feel all too bad if you found a different solution that fits your demand. To say one shoe fits all is silly.

zabzonk 3y ago

i kind of wonder why there has never been an "hghub", given that i've always liked hg rather than git. but i guess it is the torvalds connection?

nickcox 3y ago
There was bitbucket.
rstarast 3y ago
I want to say bitbucket started out as this, at least my first repos there were hg.
- zabzonk 3y ago
  yep, that's what i used to use, but it was shut down and i don't really know why - would it have cost so much to have kept it open? dunno - i really know nothing about the economics of keeping such things going.
  - mrweasel 3y ago
    I don't recall if this was before or after Atlassian bought Bitbucket, but they had a number of issues keeping the site running. There where so many outages, the site was frequently slow to the point of being useless. I know because we where a paying customer. I suspect that they had to few paying customers and because the service was so prone to outages they had acquired a bad reputation so they couldn't attract new customers. Maybe if Bitbucket had been a Silicon Valley company they would have had access to funding, allowing them to grow in the same way Github did. When it worked it was fine, but in the end you just got way better service and performance on Github. The current iteration of Bitbucket isn't even Bitbucket, it's Stash. That works really well to, if you like Atlassian tools.
bluGill 3y ago
Because you never wrote it. The curse of open source. By the time github came about, git already had a lot more mindshare than hg. While hg wasn't yet clearly an also ran, it was clearly the less popular solution, and many open source tools started supporting git but either not supporting hg, or if they did it was an afterthought and often the maintainers broke something hg without noticing and then releasing with broken hg support.

Yoric 3y ago

Snitched upon by his colleague, too! (hi glandium, sylvestre)

sylvestre 3y ago
Coucou ;)
- lizzard 3y ago
  Joining the party, that was a trip down memory lane!
  - dblohm7 3y ago
    I might as well jump in on this, too...
    - tarasglek 3y ago
      nice
      - glandium 3y ago
        Is this the thread where Mozillians assemble?
        dblohm7 3y ago
        Into that Quantum-bot exosuit thingy?

liveoneggs 3y ago

Mercurial has a quintessential "Rewrite it in rust!" page: https://wiki.mercurial-scm.org/OxidationPlan https://wiki.mercurial-scm.org/OxidationPlan

goku12 3y ago
The last update is from 2018. Did they give up?
- liveoneggs 3y ago
  the release notes imply that they are still at it
- oblio 3y ago
  Most likely. Well, it's open source, so it's "dormant".

danking00 3y ago

I've heard this point of view many times, but cannot find an extensive explanation of it. Could anyone elaborate on the issue with the GitHub review UI/UX? > I hate the GitHub review UI with a passion. At least, right now, GitHub PRs are not a viable option for Mozilla [...] the more general shortcomings in the review UI.

steveklabnik 3y ago
I know people who express similar feelings. Usually it is shorthand for "I would prefer stacked diffs" or similar. Two blog posts I've seen people point at: * https://mitchellh.com/writing/github-changesets https://mitchellh.com/writing/github-changesets * https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/ https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/
- anyonecancode 3y ago
  From the second article, a minor point but possibly helpful to other here, he contrasts doing everything in the terminal with stacked commits vs going to the Github UI. If people aren't aware, Github offers a cli tool[1]. I've been using it for a few months now and am finding it does make me more productive -- it's nice to be able to open up a PR directly from my terminal. I do still use the GH UI for a lot of things, but I'll often at least start in the terminal, and it also makes the transition from terminal to browser easy as many commands support the `--web` flag open up the right page for you (eg `gh repo view --web`). [1] https://cli.github.com/ https://cli.github.com/
  - lima 3y ago
    The CLI doesn't help with stacked commits, though. There's tools like spr[1] but none of them are anywhere as pleasant to use as Gerrit (or Phabricator, I guess). [1]: https://github.com/ejoffe/spr https://github.com/ejoffe/spr
    - anyonecancode 3y ago

CorrectHorseBat 3y ago

Linux kernel development never used cvs, I believe Linus thought it gives people brain damage and did just send around patches and tarballs

glandium 3y ago
Linus never used CVS, but there was a CVS server and the community was using it. https://flosshub.org/sites/flosshub.org/files/127-131.pdf https://flosshub.org/sites/flosshub.org/files/127-131.pdf
- bananapub 3y ago
  parts of the community, if I recall correctly, and to be clear to everyone else since I'm sure you know this: 1. linus didn't use version control at all, he just got patches emailed to him, then every now and then he'd publish a tarball and incremental patches (e.g. a 2.4.11-rc2 patch on top of 2.4.11-rc1) - the world had no visibility into his tree's development aside from the tarballs and inter-version patches he sent out 2. and because of that, no one else used version control for submitting changes, they just sent patches to lkml 3. there was some use of CVS for some ports / subsystems, but again, it was used to generate patches to email to linus 4. people built lots of tools around this work flow, like `patchwork` and horrible shell scripts
ranting-moth 3y ago
Of course you can run your project like Linux. Your first requirement is to employ Linus Torvalds as a project manager.

interroboink 3y ago

I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused with "named branches"). There was no direct equivalent to git's branches. Eventually, Mercurial got 'bookmarks' which basically closes that gap, but that only became a core feature in 2011, well after these Mozilla repos were established. ---- Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (:

glandium 3y ago
Author here. > my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). Fair point. I came up with the title first. Then as the content grew large and diluted the essence of the title, I reconsidered, but ended up sticking to it as a shameless clickbait. > Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused with "named branches"). That still leaves the question "why topic branches rather than named branches?". For the needs of the rapid release process, named branches could have been used, but weren't. I haven't tried to contact the people involved at the time to have a definite answer. It's not /that/ important, and I'm not /that/ curious.
- lynguist 3y ago
  What a beautiful post it has become nevertheless rivaling the long reads of the New Yorker and the like. I originally wanted to go to sleep but the writing was too captivating to put down, and every paragraph was motivated, and it wasn’t stretched. It was the length it needed to be.
- kbrosnan 3y ago
  Tracking down preed, JST, joduin, bsmedberg, etc might turn up stories. Some of it is captured by preed in https://soberbuildengineer.com/blog/2006/11/version-control-system-shootout-redux/index.html https://soberbuildengineer.com/blog/2006/11/version-control-... and announcing hg in https://soberbuildengineer.com/blog/2007/04/version-control-system-shootout-redux-redux/index.html https://soberbuildengineer.com/blog/2007/04/version-control-... JST post on bzr vs hg perf, https://web.archive.org/web/20070219012211/http://weblogs.mozillazine.org/jst/archives/2007/02/more_on_distributed_vcs_perfor.html https://web.archive.org/web/20070219012211/http://weblogs.mo...

oktwtf 3y ago

My only experience with Mercurial was in game development. What’s used these days in arenas where large file versioning is needed? I think the ultimate answer is maintaining an asset stack containing files that allow for inherit diff chunks or however that might be described.

swozey 3y ago
I've only used SVN and Git and I'm almost 20 years into my career at this point so I know nothing of these others but my game dev friends all use Perforce. I couldn't tell you a single thing about it though.
kaelinl 3y ago
Yeah, my understanding is that it's pretty universally Perforce in game dev. For them it's the large file versioning. I work at an ASIC firm and we similarly use Perforce; to some extent for the large file versioning, and to some extent for other general scale benefits.
WorldMaker 3y ago
Git LFS is supported by most hosts these days. It's "fine".
johnwalkr 3y ago
There's gitLFS but it requires some discipline to use.

mjhay 3y ago

Reading that article unlocked some traumatic memories of Bazaar/"bzr".

glandium 3y ago
Writing the article unlocked some traumatic memories of arch.
bombcar 3y ago
I liked bzr because it had simple to understand “versions” I could abuse to use like a single source of truth. Git requires manually applying tags to imitate it.

hexo 3y ago

Thank you, mercurial was obstacle (for me) all the time. Thanks for killing it.

sys_64738 3y ago

Solaris source control moved to Mercurial so if you want to know if it scales then the answer is yes. I miss SCCS.

yjftsjthsd-h 3y ago
Didn't Sun have Gatekeepers carefully controlling what commits were made to any given gate, thereby ensuring that the actual source control would never be the limiting factor in scaling things out? (Don't get me wrong, I love mercurial, I just don't think this particular example demonstrates much because it always sounded like they'd sidestepped the issue.)
- sys_64738 3y ago
  Yes, any putback to ON required an advocate to vouch for your change. Basically a neck to wring when things go wrong. You generally had me chance so don’t F. Up.

DominoTree 3y ago

Thank you.

wsc981 3y ago

I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest. I used Mercurial in the past for a bit, and it was fine. But for me it doesn't seem to have any huge advantages over git, if any. And after so many years of experience using git, I know what workflows work well, how to resolve merge conflicts, how to revert to an old commit if something really gets messed up, etcetera. I don't see any other DVCS really being able to replace git in the short run and I wouldn't be surprised if git will stay number 1 for the following decennia, as in my opinion it's really great software. A DVCS really has to provide substantial benefits over git in order to replace git as the number 1 DVCS.

czscout 3y ago
The sheer functionality of git is amazing. The number of times I have encountered a new situation and used a previously unknown (to me) feature, or (equally as impressive) been able to harness the flexibility of the software to wrangle some strange edge case are innumerable. All that while also being lightning fast.
cmrdporcupine 3y ago
Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names. People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way. That and there's so many ways to use it. Mercurial had the advantage of having a much more consistent UX. Though these days I'm sure I'd struggle with it, because I'm so used to git. Mercurial was never trying to "replace" git. All of these guys came out at the same time. Git got headspace because Linux used it and GitHub was a "cool" Ruby on Rails site, run by cool web 2.0 kids, same era as the rise of Twitter, etc. (And also down all the time, just like Twitter).
- bigstrat2003 3y ago
  Exactly this. To be perfectly honest, the git CLI is so bad that I would take pretty much anything over git. I would prefer SVN over git, despite that product being older and with less functionality, just because it's at least easy to use. I learned and use git because that's just how the industry has moved, and I'm pragmatic enough to just roll with it. But good Lord, the UI is a case study in "programmers shouldn't be allowed to design UIs".

riffraff 3y ago

As someone who was using darcs in that era: it wasn't just slow in the sense of "it takes 10 seconds rather than 1". It was possible to get into situations where it would take hours to merge changes. Apart from that it was the best developer experience I've had with a VCS.

BrenBarn 3y ago

I hate to see more and more people switching from Mercurial to Git. The way to overcome the "network effects" is exactly for large projects like Mozilla to stand tall and say clearly that they are going to use Mercurial because it is better and git is worse. Of course, I shouldn't really expect such from Mozilla given all the other dubious actions they've taken over time.

zarzavat 3y ago
Git won a long long time ago. Most people’s first VCS is now git. Mercurial is a lot better than SVN so it was able to pick up users back when SVN was dominant, but it’s not really better or worse than git it’s just down to taste. When you consider the network effects and switching costs it’s hard to convince anyone that mercurial is worth learning.
- iggldiggl 3y ago
  I initially picked up Git because that was the cool/recommended thing to do. Then I started contributing to Firefox and at that time the story for using Git with Firefox's Mercurial repository was much more cumbersome, so I gave up and started using Mercurial instead. Over time, Mercurial has grown on me and these days I actually prefer it over Git.
jillesvangurp 3y ago
You'd need some arguments for the assertion that mercurial is better. I think Mozilla is switching because of years of failing to come up with good arguments. And it looks like they gave it a lot of thought. That and an increasing dependence on git internally to the point where people were spending non trivial amounts of time engineering around mercurial and coming up with all sorts of hacks to enable git usage. At least, that's what the article suggests actually happened. You'll never get consensus on X being better than Y in the tech world. There are always going to be people that insist Y is better than X. And more power to them. But you have to be realistic. There is a lot of stuff that just never gets a lot of traction. Mercurial is one of those things. It's like betamax vs. vhs. Initially it looked promising and then Github happened and the rest is history. The whole industry now runs on Git and Mercurial sort of flat lined in terms of growth after Github started hosting essentially the entirety of the OSS world (with few but notable exceptions of course). At this point it's a hard sell for new projects and some of the larger remaining users are switching away or are considering it.

wirrbel 3y ago

What a shame. I came in contact with version control systems in the following order CVS (also a bit of a weird episode using RCS), Subversion, git, then mercurial I have loved git and still do. But nowadays I use mercurial for my pet projects. There is no denying that git "won", mercurial would have been a worthy alternative.

xvilka 3y ago

I hope one day Pijul[1] will become more common, as the more advanced alternative to git. [1] https://pijul.org/ https://pijul.org/

self_awareness 3y ago

I kind of like Fossil nowadays, although I'm not entirely on par with their philosophy of not squashing branches. But the "all-in-one" aspect, together with "one binary" is pretty nice.

grey_earthling 3y ago

Switching to Git makes sense, but choosing GitHub is diametrically opposed to what Mozilla claim their principles are — specifically principle 6 of the Mozilla Manifesto: “The effectiveness of the internet as a public resource depends upon interoperability (protocols, data formats, content), innovation and decentralised participation worldwide.” => https://www.mozilla.org/en-GB/about/manifesto/ https://www.mozilla.org/en-GB/about/manifesto/ In future it won't be possible to contribute to Firefox without a Microsoft account. If Microsoft decide to close your account (which they're entitled to do — they own the website), you can't participate. Mozilla were one of the few hold-outs against this particular attempted monopoly. Again, Mozilla makes a short-termist decision that makes sense for a Silicon Valley lifestyle brand, but makes no sense for an independent mission-driven public-service community project. They're an untrustworthy upstream.

seanw444 3y ago
> They're an untrustworthy upstream. All I needed to come to this conclusion was the abandonment of interesting (and necessary) projects like Servo, and the continual increase of superiors' salaries.
jamienicol 3y ago
> In future it won't be possible to contribute to Firefox without a Microsoft account What makes you think that?
- grey_earthling 3y ago
  If I understand correctly, they're moving development to GitHub, and not hosting their own git servers. So you'd need a GitHub (Microsoft) account to merge a change to the code.

BlackFingolfin 3y ago

A bit off-topic, but: I am somewhat confused by the claim “Subversion was created by Jim Blandy”. I was around back then, and the names I think of when it comes to “who created Subversion” are Ken Fogel, Ben Collins-Sussman, and Mike Pilato. And certainly many other people, including Jim Blandy. My recollection seems to be supported by e.g. https://news.apache.org/foundation/entry/the-apache-software-foundation-announces58 https://news.apache.org/foundation/entry/the-apache-software... and also by looking at the early subversion repository history and mailing list posts. But I was only a bystander (and early adopter), so maybe something went on "behind the scenes" that warrants this attribution? Or maybe it is a just a bit careless and was meant to be more like "... he was one of the creators", which one probably could justify. Coincidentally, I just checked the Wikipedia page for Subversion and was surprised that there is basically nothing on the history of Subversion and who created it, which I find sad.