4 ms·

> Facebook's problem is that they were trying to scale with Git improperly. Here's the Feb 2012 thread with Facebook's Joshua Redstone regarding their experime

> Facebook's problem is that they were trying to scale with Git improperly. Here's the Feb 2012 thread with Facebook's Joshua Redstone regarding their experiments with git: http://comments.gmane.org/gmane.comp.version-control.git/189776 http://comments.gmane.org/gmane.comp.version-control.git/189... In August 2012, they hinted they were near a solution: http://www.quora.com/Facebook-Engineering/Has-Facebook-solved-their-large-Git-repository-problem-yet/answer/Chuck-Rossi http://www.quora.com/Facebook-Engineering/Has-Facebook-solve... ...and that teaser was just today updated with the remark, "Our Mercurial team has just posted the goods! Our problems are solved, mainly by not using Git." :/

pconf 13y ago
Please correct if I'm wrong but it looks like the decision to scale using HG instead of git was made on 2 points: 1) git maintainers basically said you should split repositories and left it at that, and 2) HG's cleaner code and abstractions made it easier to patch. Fundamentally I like how this cleans up the design flaw of requiring history everywhere. 99% of the time when I clone or pull or diff or whatever I only care about HEAD. Why should I be forced to pull or store GBs of history or even MBs of metadata I can't use? Why not make leaving this data on the server optional? I can see how the decision to push history everywhere was made for simplicity but it doesn't reflect real world usage and clearly isn't scalable. Let's hope these history-option patches continue to be developed and make their way upstream. They certainly have my vote, not just as options but as defaults.