Strategies for push/merge problem?

[Alpár Jüttner]

> >> > Of course that is assuming a very CVS point of view that you
> don't need to bother to check/test the result of the fetch. Perhaps if
> the person doing this is getting emails from the central repo, they
> can know that things won't break...
> >>
> >> The only answer that actually scales is: don't use push.
> 
> The hard part about the pull model is one of resources.  How does one
> manage a pull model with 100s of repos and 100s of developers?

Do you really have 100s of developers in a flat structure with no
hierarchy at all?
I think there should be some "modules" or "components" defined, and also
with someone responsible for the development of each of those parts of
the software. These maintainers will collects (using 'pull') the
changesets that affects their territories. Then, a global maintainer
will synchronize only with the components' maintainers.

It is also important, that 'pulls' operations do not have to be as
frequent as the commits.

Finally, the "frequent commit" policy is probably a legacy of the
locking model revision systems. Using mercurial, you will typically find
it much better to commit larger block of changes, and synchronizing your
repository even less frequently, for example when you more-or-less
completely finished implementing a new feature.

> For us, the push model is the only way.

I hardly believe this. 

Best regards,
Alpar