At what point does the push model degrade?

Paul Sargent psarge at gmail.com
Sat Nov 17 05:25:43 CST 2007


On 16 Nov 2007, at 18:26, <Ezra.Smith at bentley.com>  
<Ezra.Smith at bentley.com> wrote:

> 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).

This sounds very much like how I've seen a lot of companies work.  
Everybody is trusted  the same (because they're employed), and so  
everybody has write access. It tries to keep everybody's time focused  
on the task of writing code by removing as many barriers as possible.

> 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?

I know what you're saying, and I would say no, but like you I don't  
know at what level the barrier is to this type of system working.

> 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.

Some things you may notice if you actually do this:

Because every developer now has their own repository, you may see a  
reduction in the frequency of commits/pushes to the central  
repository. Also, the central repository no longer needs to be used  
as a channel for developers to share changes (The "For me to test  
this, I need that from you. Can you check-in?" situation) so that  
takes some load off as well.

In fact the central repository becomes more like a release  
repository, and I think you'll naturally start to shift into that  
mode. Be careful though, I think it's worth keeping the central  
repository reasonably up to date, otherwise unintended consequences  
across the project don't get noticed until you're releasing. Having a  
rule such as "If you're more than a week off central, you must  
update" can help this. Just don't have everybody do it on Monday  
morning.

I'd be interested in how you get on if you do do this, because I've  
worked in several places that sound like you're describing, but I've  
yet to hear of much experience transitioning them.


More information about the Mercurial mailing list