On 01/06/2010 11:04 PM, Greg Hudson wrote:
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.
Yep, it's a valid point - both that some projects find that they cannot
get anything done, and that these projects have probably scoped their
streams to be too large.
Still, we have work spaces that are 10+ Gbytes in size with 100+ users
working on the same streams. We find that more mistakes are made in
larger projects, and the mistakes become more costly the longer it takes
for them to be discovered ("downstream consequences"). The worst case is
if the issue is discovered in the field! Looking at it this way, the
fact that it happens so frequently that it would be annoyance to a user
may be proof that something is wrong and more care (test/analyze) is
required. Using a mixed revision working copy is somewhat like sweeping
the problem under the rug and crossing our fingers. It may appear to
improve productivity, but it may have the opposite effect.
I think the only time it is safe to allow submission without update is
if the users who work on components that depend on each other always
communicate well. In the simplest case, and a common case, the code may
be broken into components, and different components problem have
"owners", and since all changes pass through these few "owners" (might
only be 1 owner for a particular area), good communication can be
ensured. In this case, I really do not care what you do in your entirely
different and unrelated component.
But, as I think you describe above - if my component is completely
unrelated to your component, why are we in the same stream? A good
answer might be to move the unrelated components to their own streams.
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>
