Whole tree up to date before committing

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Nope, there is no way around this enforcement [of whole-tree
 > consistency], so you must abide to it too when you don't need
 > it. (And even when it is a nuisance.)

If you work on an unbound branch, the check is trivial; it might as
well not be there.  I know you don't want to work on branches, but
that option is available.

 > >     In fact, if you are serious about keeping the trunk pristine,
 > 
 > I'm serious about keeping the trunk pristine.

If you're serious about keeping the trunk pristine, you have a
different definition of "pristine" than I do.  Mine is "fully tested".

 > I'm serious about productivity too, which is a larger view of the
 > issue.

All studies show that letting bugs go "just one more stage" is more
expensive in terms of developer time and/or customer satisfaction than
catching them as soon as possible.

 > >     Bazaar supports workflows that are stricter about centralized
 > >     development than Subversion. Subversion will only check that
 > >     changed files are up to date locally while Bazaar will ensure your
 > >     whole tree is up to date before committing to a *bound branch*. Why?
 > >     If your philosophy (like ours!) is that the trunk ought to be ready
 > >     to ship all the time, then used intelligently with automated testing
 > >     Bazaar's *bound branches* are one way to help keep the quality of
 > >     your trunk as high as possible.
 > 
 > 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.

I see no semantic difference between your wording and mine, just a
connotation of frustration.

 > 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.

Sure.  That's a management problem that can be addressed in several
ways.  For example, each committer can be given a "window" of time
each day when he's allowed to commit to the mainline.

 > 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.

OK, so it takes 20 hours to run the required tests, and those 20 hours
have to concentrated in about 10 hours (assuming there's some
flexibility as to when the developers work).  Since time, unlike bits,
cannot be compressed that way, your announced QA policy is *broken* no
matter what VCS you use.  Something has to give.

By using Subversion, which allows commits to files without an
up-to-date check on the rest of the tree, what you are effectively
doing is using an unbound *and unrecorded and untested* branch
workflow.  Consider the worst case: a developer lies about running
"make check" and updates his workspace before the boss gets there to
check, and you're screwed.  You cannot prove he had no successful
build because you can't reproduce his workspace, which apparently had
various files at different revisions.  Another way to put it is you
cannot bisect to find where the bug was introduced, you have to do a
full combinatorial search of all versions that "might have been" to
work out where things broke.

 > I'm sure you will realize that bazaar's policy will create a so
 > serious bottleneck that is inapplicable.

Sure, but by everybody else's definition of "pristine" you can't call
the repo that results from the Subversion policy "pristine".  *The
version in the repo* has not been tested before commit most of the
time, and your policy of having the developers run a full "make test"
on versions nobody else will ever see is a waste.  Running "make; make
my-unit-tests" only (no "make clean", no unit tests for units you
haven't touched, no integration tests) is the most you should ever ask
from your developers.  Only the buildbots should be asked to build
from a clean workspace and run all tests.

 > That project relies on a series of buildbots that continuously runs
 > on all supported platforms. After all, `make check' working on the
 > developer's machine does not mean that it works on other's.

And what happens when a buildbot goes red?  Is dealing with red
buildbots really cheaper than the branch and merge workflow?

 > So you will realize the implications of bazaar's policy: creating a
 > serialization of the commits which is unacceptable on some common
 > projects, and this is the reason why other VCSs does not inforce
 > it. Adding an option for disabling that policy would make a lot of
 > sense.

Both Mercurial and git do enforce it.  True, both have "push -f", but
that creates a new head in the common repository; it does *not* do a
merge even if it would be trivial (ie, the case where Subversion would
pass its up-to-date check: all *files touched by the commit* are up to
date, even though the *whole tree* is not).

Such merges should be extremely fast.  If the race condition created
by doing bzr merge && make test && bzr push is unacceptable (and I
agree that you would find it so in the project you describe), then
reduce it drastically by doing bzr merge && bzr push -- because that
is effectively what the Subversion policy is doing anyway.