> This is a solved problem.

Hosting a gigantic monorepo for 25K concurrent users is so far from a solved problem.

Well one. Don’t use a mono repo.

Punching yourself in the dick and then proudly proclaiming that you’ve made a robot that grabs your arm every time you go to punch yourself in the dick isn’t progress.

For a moment, let's assume they do abandon the monorepo. What solution would you recommend for managing code dependencies and coordinating releases between thousands of teams (at a modest 5 repos per team) - git tags?

This coordinating releases across teams is not a unique a problem. In fact, every large software organization solves this problem. They don’t usually do it in a assbackwards way due to institutional blindness.

You're deflecting. What solution would you recommend, since you disapprove of monorepo as a solution to this problem we both agree exists.

I disliked a lot of things about working at Meta, the monorepo was not one... it was truly amazing, and very well done.

What version control system do you consider to have solved it?

You might be surprised to learn that it was not and still is not a solved problem for companies like Meta. Here is an earlier write-up about this topic from Meta: https://engineering.fb.com/2014/01/07/core-data/scaling-merc...

Also keep in mind they've been in hypergrowth mode since 2010 or earlier. Regardless of whether Git is the clear solution today, it definitely wasn't at that time. So it makes sense they invested in building their own tooling.

And now it's 2023, and they're inventing the wheel again.

Not a very robust analogy. There are tons of different wheel designs out there. Some are good for racing and suck for rain. Some are great in the snow but are noisy and inefficient on the highway. Etc... Maybe their needs are so special they need a wheel design that doesn't commercially exist?

Someone really needs to reinvent that analogy.

You might be surprised to learn that they're solving the wrong problem.

I don't think you fully understand how big their codebase is and how many different teams are working on it at any given time.

There are very fundamental differences between a mono-repo and a bunch of repos for each "service" or whatever. Lots of tradeoffs. I've worked both and I can see the reasons for huge monorepos. They make a lot of things that were previously hard much simpler... The tradeoff is your tooling needs to be able to scale with growth of the company. And for a company the size of FB, dedicating an entire team to improving the tooling for their monorepo is well worth it.

Sit down. I worked at FB.

One year in 2014/2015?

Saying that Meta "reinvented CVS" means you either know very little about source control or you are just being purposely misleading. Neither is a very good look.

>they made their own CVS.

It is a fork of Mercurial and there wasn't a community dedicated to making it scale to the scale Meta was reaching hence why they invented resources in making Mercurial scale.

That's a very uninformed opinion. Nobody could say that unless they are capable of actually coming up with a solution that can handle version control at Meta's scale.