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