Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EdenSCM – A cross-platform, scalable source control management system

github.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: EdenSCM – A cross-platform, scalable source control management system

#21

Post by vlovich123 »

masklinn wrote: post #15
wincent wrote: post #9

Earlier quoted context omitted.

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.661…

> 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. Which is about the same thing, mercurial was built to be at least somewhat pluggable, so facebook could build their extensions independently, and work to get a su…

Of the five largest tech companies only 1 has created a mono repo in git after Google and Facebook chose mercurial and started proving it out. I think it’s less about what the project was designed for and the communities ability to appreciate the challenges facing these large companies. You can tell from the post because all the feedback is “have you tried doing something totally different” rather than “that’s an interesting scaling challenge - how can we make git perform better at scale? what are the properties we’d have to trade off? how do we manage that tension or is this really fundamentally incompatible and if so clearly communicating why it’s incompatible with the project’s goals”.

At a technical level I believe both Google and Facebook engineers make core changes to mercurial when they need to so I don’t think that’s the root philosophical difference.

Re: EdenSCM – A cross-platform, scalable source control management system

#23

Post by eitland »

jboynyc wrote: post #18
eitland wrote: post #16

BTW : with so many smart and connected people interested in source control management in one place, does anyone know what happened to veracity scm ( http://veracity-scm.com )? It was very promising but the suddenly stopped updating and then (more or less intentionally it seemed) links stopped working, but the site is still up 7 years later...

The developers went on to work on other things: https://web.archive.org/web/20130915093113/veracity-scm.com/...

ah, thanks, I tried to figure out for years because I felt they got so much right ux wise.

Re: EdenSCM – A cross-platform, scalable source control management system

#24

Post by rakoo »

StephenAmar wrote: post #12
Game_Ender wrote: post #4

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/

And Google has Piper and Srcfs http://google-engtools.blogspot.com/2011/06/build-in-cloud-a...

I found this piece to have all the interesting details: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

Re: EdenSCM – A cross-platform, scalable source control management system

#25

Post by mrmonkeyman »

searchableguy wrote: post #7
Game_Ender wrote: post #4

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/

Curious why facebook went for mercurial?

They think 15gb monorepos are normal and sane and will bend reality itself to make it work.

Re: EdenSCM – A cross-platform, scalable source control management system

#26

Post by smilliken »

m12k wrote: post #6

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 bu…

Nix has a build cache which is keyed by a hash of the build inputs, so a package will only be rebuilt if sources or dependencies change. The cache is immutable and is populated on demand from the network. https://nixos.org/nix/

Re: EdenSCM – A cross-platform, scalable source control management system

#27

Post by rakoo »

m12k wrote: post #6

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 bu…

This is exactly what Google's internal system does: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

The SCM, the CI, the Merge Request system, the build system, they're all tied together into a single thing. Google has open sourced parts of it but nothing exists as a whole unit the way Google does it

Re: EdenSCM – A cross-platform, scalable source control management system

#28

Post by qznc »

> A virtual filesystem for speeding up the performance of source control checkouts.

To describe it as a filesystem matches my thinking [0]: "It already resembles a network file system, so it should provide an interface nearly as easy to use."

If it really takes off as an Open Source project, we might be able to "mount" repostories eventually.

[0] http://beza1e1.tuxen.de/monorepo_vcs.html

Re: EdenSCM – A cross-platform, scalable source control management system

#29

Post by _0w8t »

gen220 wrote: post #14
wincent wrote: post #9

Earlier quoted context omitted.

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.661…

This was a super fun read, thanks for sharing. The mailing list piece is from 2012, and describes how git is very slow on a synthetic repo with millions of files and commits. Today, my current place of work has a monorepo that’s approaching the size described in this mailing list, but git seems to be holding up just fine. If you checkout a branch that’s far enough away from master it takes a minute, but add, rebase,…

Git works nicely on Linux for Chromium with over 540K files spread across a few modules. On Mac and Windows it is kind of tolerable, but with git status taking 5 or more seconds, I started to use “git status directory” to get more instant feedback. And git blame can take more than a minute, so it is often better to look at the log and guess the changes from it.

Re: EdenSCM – A cross-platform, scalable source control management system

#30

Post by cat199 »

qznc wrote: post #28

> A virtual filesystem for speeding up the performance of source control checkouts. To describe it as a filesystem matches my thinking [0]: "It already resembles a network file system, so it should provide an interface nearly as easy to use." If it really takes off as an Open Source project, we might be able to "mount" repostories eventually. [0] http://beza1e1.tuxen.de/monorepo_vcs.html

> we might be able to "mount" repostories eventually.

a) https://github.com/presslabs/gitfs

b) https://en.wikipedia.org/wiki/Rational_ClearCase#History

Post reply on HN