https://news.ycombinator.com/item?id=23124095 Game_Ender 30 minutes ago [-]
Facebook rewrote Mercurial, while Microsoft has essentially expanded git with their own virtual file system VFSforGit [0] and a bunch of performance improvements.
0 -
https://vfsforgit.org/ StephenAmar 13 minutes ago [-]
And Google has Piper and Srcfs
http://google-engtools.blogspot.com/2011/06/build-in-cloud-a... searchableguy 22 minutes ago [-]
Curious why facebook went for mercurial?
wincent 18 minutes ago [-]
They explain it here:
https://engineering.fb.com/core-data/scaling-mercurial-at-fa...The official reason is that the "internals of Git" weren't conduce to the kinds of invasive changes they needed/wanted. But I think the truth is closer to being that it was going to be too hard/slow to get those invasive changes past the Git mailing list.
Here's an example of a FB eng reaching out to the mailing list:
http://git.661346.n2.nabble.com/Git-performance-results-on-a... searchableguy 14 minutes ago [-]
Some responses are funny.
Have you considered upgrading all of engineering to SSDs? 200+GB SSDs are under $400USD nowadays.
kyrra 7 minutes ago [-]
(googler, opinions are my own)
Google interestingly also still contributes to mercurial[0], but I don't think has said why externally officially.
But yes, my understanding is that mercurial is much easier to replace parts of the flow without entirely hacking the codebase to bits. Microsoft's solution for git required them to fork the code base, which I still don't think has been fully merged with upstream yet? And as others said, the mercurial community was more open to enterprise contributing things than git can be.
https://www.mercurial-scm.org/wiki/5.2sprint m12k 27 minutes ago [-]
Does this work together with a build cache? My dream setup for dealing with building huge code bases is a file system integrated with the version control system to only download files when they are accessed (which sounds like what this does) but also employing a build cache and module system, so it doesn't even need to download and compile any module that has not been touched, it just downloads the result from the build cache instead.
kyrra 18 minutes ago [-]
Seems like they can be separated systems. For example, Google's Bazel supports build caches.
https://docs.bazel.build/versions/master/remote-caching.html beagle3 28 minutes ago [-]
There is more tooling needed in general - just one recursive grep will populate the entire EdenFS.
I suppose FB has better tools. But I won’t touch this until the ecosystem is sufficient (and also, because git and hg are perfectly sufficient for the monorepo I oversee)
wincent 21 minutes ago [-]
The file system, the VCS, and the ability to index/grep the repo are just the tip of the iceberg. Pretty much everything that needs to access the filesystem or which depends on the contents/structure of the repo in some way needs to be re-built from scratch or otherwise dramatically customized to operate in this new landscape. That means a long catalog of tools and many years of effort.
This was already starting to become true even before FB switched to Eden, and before it switched to Mercurial (grepping, for example, was already back in the Git days being served by a custom grep service).
amelius 1 hour ago [-]
Interesting. This might be a step in the direction of being able to store big files in repositories without hassle.
However, perhaps OS level support would be preferred. Imagine you have a type of symbolic link that is not just followed, but executed when you access it. That would be really powerful and would allow this kind of optimization. And you wouldn't even need to install or run anything.
oconnor663 49 minutes ago [-]
Sounds a lot like FUSE?