3 ms·

FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engi

by 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.
fmajid 3y ago
Git has a lot of warts, but if I were to pick an alternative it would be Fossil, not Mercurial. I believe Meta’s implementation includes server components (Mononoke) that were not open-sourced, or at least not buildable without closed-source dependencies. Same with Microsoft’s fork of git that relies on a virtual filesystem, but that one is open-sourced, if for Windows, not Linux.
- petre 3y ago
  Mercurial is dead unfortunately. It's been stuck on Python 2. The CLI was saner than Git but it needed Python, which helped with our (better) decision to pick Fossil instead. This was 11 years ago. It's been great, it has everything you need in a single executable which can be statically compiled.
  - rbehrends 3y ago
    Mercurial runs on Python 3 just fine and has been for a while. In fact, starting with Mercurial 6.2 (from July 2022), Python 2 is no longer supported [1]. [1] https://wiki.mercurial-scm.org/Release6.2 https://wiki.mercurial-scm.org/Release6.2
  - alwillis 3y ago
    > Mercurial is dead unfortunately. It's been stuck on Python 2. Mercurial adopted Python 3 a while ago. Not to mention, huge chunks of it have been rewritten in Rust. Mercurial has continued to get new features like Changeset Evolution [1] that once you use it, you wonder why all version control systems don’t have it. [1]: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/
rbehrends 3y ago
As somebody who has actually been using Sapling (because it provides a much saner UI and mental model than git), the git compatibility of Sapling is at best so-so. It feels more like a stopgap solution while they're evolving their own backend (which I'm pretty sure they use internally, because git just doesn't scale to FB monorepo size and doesn't support their rebase-on-push operation). LFS flat-out doesn't work with Sapling. Force pushing after an amend or rebase is still cumbersome, because you need to explicitly specify (again) the branch you are pushing to. And I'm not sure how bad the file descriptor problem still is that you have (had?) with large repos or submodules [1]; there was a new release recently, but I haven't actually stress-tested that. [1] At least some of that may be due to file descriptor leaks: https://github.com/facebook/sapling/issues/464 https://github.com/facebook/sapling/issues/464
kyrra 3y ago
And Google has been putting much of their investment behind jj. One other interesting thing I've noticed, mercurial has stopped building windows standalone releases. It's been that way for around 9 months.
- saagarjha 3y ago
  What’s jj?
  - chronogram 3y ago
    https://github.com/martinvonz/jj https://github.com/martinvonz/jj a more recent version control system.
  - deleted 3y ago
    [deleted]
- depr 3y ago
  Have they? It seems there's only one Google employee working on it.
- muxator 3y ago
  I think Matt Harbison takes care of Windows builds. They are bundled with the official TortoiseHg download: https://tortoisehg.bitbucket.io/download/ https://tortoisehg.bitbucket.io/download/ I did not use them because I am on linux only, but I see that Matt is active and responsive, both on the mailing list and chasing bugs on the issue tracker on heptapod ( https://foss.heptapod.net/mercurial/tortoisehg/thg https://foss.heptapod.net/mercurial/tortoisehg/thg )
loeg 3y ago
The day-to-day workflow at Meta is still using the hg frontend and regular hg commands. I would love to see the git frontend used instead, but, it hasn't happened yet.
- Kilenaitor 3y ago
  I've switched over to using `sl` commands. Sapling is installed on ODs by default. Main change I had to get used to was `up(date)` became `goto`.
  - loeg 3y ago
    I don't want to learn a 3rd thing that isn't git!
  - cozzyd 3y ago
    I assume this is a different sl than https://man.cx/sl(6) https://man.cx/sl(6)
    - mrweasel 3y ago
      While the real sl (Steam Locomotive) isn't installed on that many systems, I can only imagine the annoyance that it must bring to any former Facebook engineers when they assume that it's the version control
      - cozzyd 3y ago
        I wonder how many typoed invocations of ls correspond to sl commands. Like if you have an update directory. Although now that I think about it, if hg had displayed a steam locomotive, maybe people wouldn't have noticed how slow it was...

by wmf 3y ago

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.

fmajid 3y ago

Git has a lot of warts, but if I were to pick an alternative it would be Fossil, not Mercurial. I believe Meta’s implementation includes server components (Mononoke) that were not open-sourced, or at least not buildable without closed-source dependencies. Same with Microsoft’s fork of git that relies on a virtual filesystem, but that one is open-sourced, if for Windows, not Linux.

petre 3y ago
Mercurial is dead unfortunately. It's been stuck on Python 2. The CLI was saner than Git but it needed Python, which helped with our (better) decision to pick Fossil instead. This was 11 years ago. It's been great, it has everything you need in a single executable which can be statically compiled.
- rbehrends 3y ago
  Mercurial runs on Python 3 just fine and has been for a while. In fact, starting with Mercurial 6.2 (from July 2022), Python 2 is no longer supported [1]. [1] https://wiki.mercurial-scm.org/Release6.2 https://wiki.mercurial-scm.org/Release6.2
- alwillis 3y ago
  > Mercurial is dead unfortunately. It's been stuck on Python 2. Mercurial adopted Python 3 a while ago. Not to mention, huge chunks of it have been rewritten in Rust. Mercurial has continued to get new features like Changeset Evolution [1] that once you use it, you wonder why all version control systems don’t have it. [1]: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/

rbehrends 3y ago

As somebody who has actually been using Sapling (because it provides a much saner UI and mental model than git), the git compatibility of Sapling is at best so-so. It feels more like a stopgap solution while they're evolving their own backend (which I'm pretty sure they use internally, because git just doesn't scale to FB monorepo size and doesn't support their rebase-on-push operation). LFS flat-out doesn't work with Sapling. Force pushing after an amend or rebase is still cumbersome, because you need to explicitly specify (again) the branch you are pushing to. And I'm not sure how bad the file descriptor problem still is that you have (had?) with large repos or submodules [1]; there was a new release recently, but I haven't actually stress-tested that. [1] At least some of that may be due to file descriptor leaks: https://github.com/facebook/sapling/issues/464 https://github.com/facebook/sapling/issues/464

kyrra 3y ago

And Google has been putting much of their investment behind jj. One other interesting thing I've noticed, mercurial has stopped building windows standalone releases. It's been that way for around 9 months.

saagarjha 3y ago
What’s jj?
- chronogram 3y ago
  https://github.com/martinvonz/jj https://github.com/martinvonz/jj a more recent version control system.
- deleted 3y ago
  [deleted]
depr 3y ago
Have they? It seems there's only one Google employee working on it.
muxator 3y ago
I think Matt Harbison takes care of Windows builds. They are bundled with the official TortoiseHg download: https://tortoisehg.bitbucket.io/download/ https://tortoisehg.bitbucket.io/download/ I did not use them because I am on linux only, but I see that Matt is active and responsive, both on the mailing list and chasing bugs on the issue tracker on heptapod ( https://foss.heptapod.net/mercurial/tortoisehg/thg https://foss.heptapod.net/mercurial/tortoisehg/thg )

loeg 3y ago

The day-to-day workflow at Meta is still using the hg frontend and regular hg commands. I would love to see the git frontend used instead, but, it hasn't happened yet.

Kilenaitor 3y ago
I've switched over to using `sl` commands. Sapling is installed on ODs by default. Main change I had to get used to was `up(date)` became `goto`.
- loeg 3y ago
  I don't want to learn a 3rd thing that isn't git!
- cozzyd 3y ago
  I assume this is a different sl than https://man.cx/sl(6) https://man.cx/sl(6)
  - mrweasel 3y ago
    While the real sl (Steam Locomotive) isn't installed on that many systems, I can only imagine the annoyance that it must bring to any former Facebook engineers when they assume that it's the version control
    - cozzyd 3y ago
      I wonder how many typoed invocations of ls correspond to sl commands. Like if you have an update directory. Although now that I think about it, if hg had displayed a steam locomotive, maybe people wouldn't have noticed how slow it was...