At what point does the push model degrade?

[Ezra.Smith at bentley.com]

Bryan O'Sullivan wrote:
> This problem isn't unique to Mercurial: any revision control system 
> where you have a lot of people working out of the same tree will 
> encounter the same problem.

Fair enough, but we're transitioning from CVS, where revisions are on a per-file basis. Right now it's an extremely rare situation where I can pull the latest revision of a specific file, merge my changes in, and try to push...only to find that someone else has done the same thing with the same file. On the other hand, I see it as quite likely that I'll pull the latest changes in a Mercurial repository, do my merge, and try to push...only to find that someone has pushed something unrelated to my file, but has still changed the tip and forced me to merge again.

> Having a central repository is not a problem.  You're very likely to run 
> into problems if you let everyone push to that single central 
> repository, though.

> If someone finds that their push is blocked by a need to pull and merge 
> first, and you have a sufficiently large number of users, there's a high 
> likelihood that any given user will finish a merge and find that they've 
> lost a race against someone else, and so have to merge again before they 
> can push.

This is mostly where I'm concerned. I don't really know what "sufficiently large" is, and I'm hoping that it's larger than what we have. Right now we have some 50-100 people who do have write access to our central repository. Most of those people have multiple roles and don't belong to a single specific team (and, in many cases, there may not be a "team" involved in what they're doing).

My major problem with the open source model is that there are implied degrees of trust determining whose changes propagate to the central repository. People at each level of that chain serve an actual purpose: filtering the good changes from the bad, and deciding what should continue moving up the chain. And as a byproduct of their actual purpose, they're also devoting some of their time to packaging many smaller commits into one larger delivery, which relieves strain on the level above them. But if you remove the need for filtering and assume that everyone can make changes to the central source tree...is it worth maintaining a commit chain solely for the secondary benefit of packaging changes from many people into a single push?

Decentralization does make good sense, though, even if it isn't always hierarchical. I think we may be best off with a 100-person push system that emphasizes collaboration away from the central server where possible.

In any case, your suggestions are much appreciated!

Thanks,
-Ezra