[acac10]

I think the takeaway from your comment is that you really do not understand the sheer scale of volume of changes done by +100k engineers, their heavy reliance on tools that do cluster-based testing (not local dev machine) and the tens of thousands of tools that perform auto-commits.

It’s a lot easier to shit on a big corp. Intellectually lazy, too.

[floating-io]

Are you saying that GitHub and GitLab.com don't have that kind of volume?

(edit: the point being that at least one of those tools existed when they started Piper if I have the timeline correct).

[Xeamek]

>Are you saying that GitHub and GitLab.com don't have that kind of volume?

On a single project? Verry much doubt either of them do

[floating-io]

Yeah, that's moving the goalposts.

The point is that either product should theoretically have the ability to handle Google's load. They were both built for scale. If I have the timeline correct, they existed at that point. I would expect those organizations to have positively salivated at the possibility of having Google as a customer; they would have bent over backwards to make it support Google's workflows.

The ROI of such a choice vs going custom is the interesting question.

Of course, if I have the timeline wrong, then the discussion is moot.

[tylerhou]

There is a big difference between one VCS handling 1,000 QPS and 1,000,000 VCS instances each handling 0.001 QPS. A system built for one is not necessarily suitable for the other.

[floating-io]

See my response to bananapub below.

[kccqzy]

It's not moving the goalpost because you didn't understand where the goalpost was in the first place.

Lots of tiny repos like GitHub? Easy sharding problem. They don't even need Paxos. One large monorepo? Everything changes. Let us not forget that GitHub cannot even handle the Homebrew repo be cloned and updated by Mac users and asked them to switch to a CDN.

[Xeamek]

Its not moving the goalpost, it's part of google's requirements that make their case unique (at least more than average)