Whole tree up to date before committing

[Nicholas Allen]

> 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's easy enough to have multiple developers
committing on the same branch in Bazaar. You just need to do an update
before you commit or use a gatekeeper style workflow if you want some
kind of quality control on the trunk.
>
> I'm serious about keeping the trunk pristine. I'm serious about
> productivity too, which is a larger view of the issue.
>   
You can't be serious about keeping the trunk pristine if you allow it to
get into a state that has not existed for any developer. The gatekeeper
workflow would allow you to keep trunk pristine and developer
productivity high.
>
> Even discarding my observation about distributed workflows being
> equivalent to centralized ones wrt this topic, the honest wording would
> be: using bound branches forces a check that insures that your whole
> tree is up to date before you can commit your changes. This has the
> advantage of lessening the chances of a broken build, but may create a
> bottleneck when several developers commit their changes within a narrow
> timeframe.
>   
True, but if you have that many commits and developers then investing in
the gatekeeper approach would make more sense.
> Yes, it is :-)
>
> 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? What's the point in making a developer run make check but
allow the trunk to get into a state where this could fail? How do you
ensure that they have really run make check?

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

Cheers,

Nick