At what point does the push model degrade?

[Ezra.Smith at bentley.com]

Hello all,

We're looking to change over to Mercurial because we like a lot of the
benefits. But we're suffering from a "last mile" problem. Most of the
plan is obvious to us, but we're not entirely sure how to maintain our
central repository (note: we definitely do need one). Although we have a
lot of developers, the most working on any given repository isn't that
large, maybe 50-100. Will a push model scale to that size? Does anyone
have experience with pushing to a central repository with a lot of
developers? And at what point do you think that a centralized push
system will break down?

In the obvious case, the Linux kernel would be a horrible place to have
everyone pushing to a central repository and doing pull/merge/push to
prevent multiple heads. I know there was even a recent post about lock
contention and ramping up to 99% as more and more people are trying to
push. I don't think we'd be anywhere near that level of contention, but
at what point would I get so annoyed by having to pull/merge/push only
to find that someone else did the same thing during my merge, and now I
have to pull/merge/push again, only to find that another person did the
same thing...etc? On the order of hundreds? Thousands? Tens? In theory,
I think the quick turn around on a pull, trivial merge, and push will be
enough to stop me from colliding with new heads all the time. What I'd
really like to know is if anyone has tried it in practice, and if that's
actually the case.

Here's some additional information:
What we'd like to have is essentially two central repositories. The
first one is where developers put their changes, and then those changes
are pushed to the second repository once they have been integrated,
compiled, and tested. So you're always pulling from a known good place,
and you're pushing to a place where the automated systems pull the data.
When I read the documentation, it talks about three levels of sharing:
meetings, small companies, and Linus. My impression is that small
companies are 10-20 developers, so we're maybe five times that large. We
don't want to go with the Linus model for several reasons. First off, we
don't have anyone who knows all the source; there is an awful lot of it.
Second, we are globally distributed. Typically a developer can commit
their changes in the morning and find out within a couple hours from the
automated systems if there are any problems. The sooner after a change
that the problem is reported, the better. And third, people take
vacation, get sick, go on jury duty, etc., and whomever is in charge of
pulling could be gone on any given day.  Even if there were two or three
people that knew the source, with one on vacation and another sick it
could shut down commits for days, which ripples through testing, etc. In
software development, it is difficult enough to predict a schedule
without adding another unknown into the mix.  While I won't argue the
effectiveness of the Linus model, I don't think it is generally
applicable, and we don't really want to have gatekeepers funneling
source code up a distributed pyramid.

I'm also not positive that our suggested work flow is correct, so I'm
open to alternatives there.

Thanks,
-Ezra