Whole tree up to date before committing

[Óscar Fuentes]

Nicholas Allen <nick.allen at onlinehome.de> writes:

>> Nope, there is no way around this enforcement, so you must abide to it
>> too when you don't need it. (And even when it is a nuisance.)
>>   
> I can't see how it can ever be a nuisance to have what you committed the
> same as what you or someone else will checkout. This seems like a
> mis-feature of subversion.

It is implicit on my previous message that bazaar's policy is the ideal
one, but subversion's is a tradeoff.

[snip]

>> One project where I partipate has about 20 daily committers, which
>> combined make an average of about 100 commits per day. Most of them
>> work on the same timezone, so commits tend to concentrate on the same
>> hours. As they are serious about keeping the build pristine, a full
>> `make check' is mandatory before committing code changes (let's say
>> there are 60 of those per day). Building the project and running the
>> test suite takes about 20 minutes on a state-of-the-art workstation. I'm
>> sure you will realize that bazaar's policy will create a so serious
>> bottleneck that is inapplicable.
>>   
> Wouldn't it make sense for those developers to work in their own
> branches and only merge that to trunk when their branch is considered
> complete?

No. Most of the commits are not large features, but small bug fixes and
additions. If you accumulate several small changes on your private
branch, you are adding complexity for when those are merged into
trunk. For instance: if some change breaks the build on a platform other
than the developer's, this may be not detected until several hours
later, if the changes are incorporated in batches to trunk, as the
buildbots must test every revision.

> What's the point in making a developer run make check but
> allow the trunk to get into a state where this could fail?

It is one layer of quality control: first the developer, then the
buildbots, etc. BTW, doing a bzr-style commit on Linux/x86_64/gcc does
not guarantee that the build does not break on Windows/x86/VS, for
instance.

> How do you ensure that they have really run make check?

And how do you ensure that they revised the merged changes before
committing them?

> It seems to me that a gatekeeper style workflow would be the best in
> this situation.

Although some projects with a strong and committed leader succesfully
follows that policy, most can't afford that luxury: gatekeepers need to
have high availability, be experts on their responsibility area, have
communication skills, have several of them in case someone catches the
flu, etc. and, finally, you are devoting highly skilled developers to
doing "office work" which delays the project's progress. This poses a
problem on its own and is no solution for bazaar's self-imposed
limitation.

-- 
Óscar