[reissbaker]

When I was at Meta, using the custom VCS tooling was pretty great, especially considering the repo size. That being said, for both this and Jujutsu, I feel like without open-sourcing the secret sauce (the super-scalable backend), it's hard to understand why anyone outside of the respective orgs would adopt; it's a not-well-known layer on top of Git, which is:

a) Known by almost anyone you're likely to hire or work with, and

b) Will have all the same scalability problems with large monorepos regardless of what client you're using.

If Sapling and Jujutsu don't solve the scaling problems, and everyone already knows git (and you're still using git under the hood), what's the point?

It's nice that it's open-source but to get traction I feel like they need to open-source the backends. I'm sure plenty of mid-sized companies struggling to manage their git repos would be happy to use the Meta/Google solution to the problem, but neither of these projects includes the part where the problem gets solved.

[ahahahahah]

They've actually open sourced almost everything you need. It includes the cli, the virtual filesystem, and the backend.

From github:

Sapling SCM is comprised of three main components:

The Sapling client: The client-side sl command line and web interface for users to interact with Sapling SCM.

Mononoke: A highly scalable distributed source control server. (Not yet supported publicly.)

EdenFS: A virtual filesystem for efficiently checking out large repositories. (Not yet supported publicly.)

And from the mononoke page:

Mononoke is still in development. We are making it available now because we plan to start making references to it from our other open source projects.

The version that we provide on GitHub is omitting some functions.

This is because the code is exported verbatim from an internal repository at Facebook, and not all of the scaffolding from our internal repository can be easily extracted. The key areas where we need to shore things up are:

Support for running thrift based apis.

Production metadata SQL support (e.g. something like a MySQL backend). We provide sqlite in OSS for now.

Production blobstore storage backends (e.g. something like S3). We provide SQL (on sqlite) and File System backends currently in OSS.

Linux is Mononoke's primary target plaform with OSS CI also running on MacOS. Other Unix-like OSes may be supported in the future.

[reissbaker]

I would say "not yet supported publicly" is a pretty big caveat — especially because neither Eden nor Mononoke (according to the README) actually build if you only have access to the open-source tools. Not sure if I'd call source dumps that don't successfully build "almost everything you need" ;)

I'm not holding my breath either; EdenFS was open-sourced many years ago with broken-for-OSS builds IIRC; it doesn't seem like there's much urgency in getting it buildable using tools available to non-Meta-employees.

[alexhornby]

Check GitHub actions. Mononoke OSS currently builds and EdenFS did a month or so ago. Not claiming it’s perfect, but the OSS versions are buildable

[reissbaker]

Oh interesting — the README says they don't, but it must be outdated. Pleasantly surprised to hear they build now, albeit inconsistently.

[alexhornby]

EdenFS Linux building now as well, problem was some minor python 3.8 incompatibility in a test

[Shish2k]

> it's hard to understand why anyone outside of the respective orgs would adopt

Personally I don’t care about the backend at all - I’m loving sapling just as an alternative git frontend with considerably better UX :)

[loeg]

It's different, but I'd hesitate to call it better. I've been using it for work for over three years now and still regularly get tripped up by weird behavior or missing functionality relative to git. And it's not portable to other employers, because almost no one uses hg/sapling.