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

11–20 of 33 posts

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

#11

Post by searchableguy »

wincent wrote: post #9
searchableguy wrote: post #7

Earlier quoted context omitted.

Curious why facebook went for mercurial?

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…

Some responses are funny.

> Have you considered upgrading all of engineering to SSDs? 200+GB SSDs are under $400USD nowadays.

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

#12

Post by StephenAmar »

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

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

#13

Post by kyrra »

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?

(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

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

#14

Post by gen220 »

wincent wrote: post #9
searchableguy wrote: post #7

Earlier quoted context omitted.

Curious why facebook went for mercurial?

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, commit, status and blame are all negligibly impacted speed-wise. The only issue we run into is rejected non-conflicting pushes to master during peak hours, with maybe several dozens of engineers trying to merge and push master simultaneously.

Does anybody have any insight into what’s changed in git internally since 2012 to support bigger repos?

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

#15

Post by masklinn »

wincent wrote: post #9
searchableguy wrote: post #7

Earlier quoted context omitted.

Curious why facebook went for mercurial?

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 subset of them integrated into mainline. Git is designed so it can be built on top of, but not really under or within.

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

#16

Post by eitland »

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

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

#17

Post by beagle3 »

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

I don’t think there is one single change that made a huge difference. I follow the changelogs posted on the mailing list, and of the performance related changes, it’s often “we got 3-5% speed up on this benchmark on this fs without making things worse on others”.

Over 8 years and tens of those changes, it adds up to a significant performance improvement.

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

#18

Post by jboynyc »

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/...

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

#19

Post by stcredzero »

wincent wrote: post #9
searchableguy wrote: post #7

Earlier quoted context omitted.

Curious why facebook went for mercurial?

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.

Funny, but I'm starting to wonder if there's an affect-based complement to Conway's Law.

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

#20

Post by chadaustin »

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…

EdenFS makes it possible to query for hashes of files so any cached outputs can be looked up from the build cache without having to download the source control. There’s more to do here, but that’s a big benefit of having a custom filesystem.
Post reply on HN