On Wed, 2010-01-06 at 21:26 -0500, Mark Mielke wrote: > There is a race between the pull > and push whereby somebody who pushes before I pull will cause my push to > fail, but we generally consider this a good thing as it allows us to > analyze the change and determine whether additional testing is required > before we try to submit "pull and push" again.
I've certainly heard this argument before, and I think it makes sense for some projects. However, I've heard from some people that they work on projects where they would never be able to get any work done (that is, they would never be able to commit anything in a reasonable amount of time) if they always had to pull before pushing and hope that no one else pushes in the mean time. Those projects are simply too active to support a "pull, test/analyze, and push" development model. In some cases this is because "the project" has been defined to be larger than it really needs to be. For instance, the ASF repository would be pretty frustrating to use if always you had to be up to date before committing, but it's easy to see how the ASF might have created separate repositories for each project instead of what it did. In other cases "the project" is not so easily subdivided.
