Scaling Mercurial at Facebook • Hacker News Board

Re: Scaling Mercurial at Facebook

#241

Post by Pxtl » Fri, Jan 10, 2014, 1:38 AM UTC

jaredsohn wrote: post #240

com2kid wrote: post #239

Earlier quoted context omitted.

I'd say 70% of the projects I know about in MS use .NET. All web sites are of course written in ASP.NET. Giant portions of the Xbox Live service are written in .NET. Heck lots of tools and utilities are also .NET based. Is someone going to rewrite IE in C#? Not likely, that isn't what C# is for.

I think that sentiment comes from Microsoft saying back in the day (if I remember right) that they were going to rewrite much of their user software (such as MS Office) to use .NET.

Exactly. I doubt there's a single piece of .NET client-side software that a non-geek has heard of (Word, IE, paint, etc.).

Re: Scaling Mercurial at Facebook

#242

Post by pconf » Fri, Jan 10, 2014, 7:21 PM UTC

justinmk wrote: post #57

Crito wrote: post #24

I wrote a comment about the scaling of repositories (and specifically Facebook's issues) a few days ago that was wiped out by the HN crash, but I've managed to recover it from HNSearch: Facebook's problem is that they were trying to scale with Git improperly. With conventional CVS[sic] systems like Perforce, you can scale a single repo nearly as large as any company will need. Emphasis on that nearly. At a certain po…

> 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/189... In August 2012, they hinted they were near a solution: http://www.quora.com/Facebook-Engineering/Has-Facebook-solve... ...and that teaser was just today updated with the remark, "Our…

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.

Re: Scaling Mercurial at Facebook

#243

Post by com2kid » Fri, Jan 10, 2014, 7:21 PM UTC

Pxtl wrote: post #241

jaredsohn wrote: post #240

Earlier quoted context omitted.

I think that sentiment comes from Microsoft saying back in the day (if I remember right) that they were going to rewrite much of their user software (such as MS Office) to use .NET.

Exactly. I doubt there's a single piece of .NET client-side software that a non-geek has heard of (Word, IE, paint, etc.).

Microsoft uses .NET a-plenty. Saying that brief marketing hype of over a decade ago isn't lived up to is a bit disingenuous. MS ships numerous apps in C#. Check out the Windows Store and WP Store, I know for a fact lots of MS's stuff in there is C# based. I cannot say for sure what Desktop apps are C# based because, well, it isn't exactly obvious!

C# isn't being used as a systems programming language, but it isn't meant to be one. (That said, I've written high performance code in C# before, you have to know what you are doing and understand your GC, same as writing high performance code in Java!)

Tons of LOB software internal to MS (indeed I'd say the vast, vast, majority of internal LOB software) uses C#. Lots of plugins and extensions to various tools use C#, and I wouldn't be surprised if lots of the PowerShell Cmdlets and Modules are C# based.

Now I have worked on a number of commercial projects that were written in C#, but of course I am unable to discuss them!

(None of this is spoken of as an official MS employee of course, it is not but my own opinions!)

Re: Scaling Mercurial at Facebook

#244

Post by tshepang » Mon, Jan 13, 2014, 6:39 PM UTC

novaleaf wrote: post #114

agwa wrote: post #39

For some context of why Facebook choose Hg over Git, here's the mailing list thread where Facebook initially reached out to the Git developers: http://thread.gmane.org/gmane.comp.version-control.git/18977...

I personally love mercurial (simpler than git), and have been a bit nervious over the last year or so with the mindshare shift to git. So hearing about this (FB all in with hg) ensures that hg won't be falling behind... at least in the nearterm.

I created this list to help me stop worrying: http://tshepang.net/major-projects-using-mercurial.

Re: Scaling Mercurial at Facebook

#245

Post by tshepang » Mon, Jan 13, 2014, 6:51 PM UTC

watt wrote: post #180

durin42 wrote: post #12

Earlier quoted context omitted.

Note that extensions that ship with Mercurial are exactly as supported as the tool itself, and come with the same kinds of backwards compatibility guarantees. It's not worth worrying about rebase, histedit, and record being extensions - if you want them, turn them on and use them.

The fact they are not on by default seems to actually be hurting Mercurial in the debate against Git. As every review of "Mercurial vs Git" assumes they are not available, just because they are not enabled in default configuration out of the box. Maybe Mercurial should start shipping them enabled?

I would rather they be made easier to enable (currently one has to edit an .INI file). That would be better than trying to appease some hypothetical from-Git converts.