Whole tree up to date before committing

[Nicholas Allen]

> Code changes without building and running the test suite are
> forbidden. Period.
>   
Not in your subversion setup. A developer can commit something he has
not tested but it seems you want this behaviour. If that's the case then
write a script (it would probably be 3 lines long in bash or python)
that updates and commits in a loop until success or conflicts are
encountered. Then you have an *identical workflow* to what you currently
have.

When a developer commits they just run this script instead of bzr commit.
> Too often I judged a change trivial, commit it and later had to confront
> some angry fellows. 
Exactly why a gatekeeper approach would be so much better IMO.
> Maybe a full build can be avoided if the change is
> very localized, but I would think thrice before committing without
> running the test suite.
>
> So the workflow would be:
>
>  1. Re-build and run the test suite. This will take 20 minutes on a
>  fast Linux machine, 1 hour on a fast Windows machine. Meanwhile, work
>  on something else using other local feature branch.
>  2. If okay, re-sync my local branch with master and see if this
>  introduces code changes.
>  3. If yes, go to step 1.
>  4. Push to master.
Not it wouldn't. If you *really* want the same behaviour as you have now
then it can be achieved with bazaar using a very simple script.

Personally, I can't see the benefit in that kind of workflow. I would
prefer to automate things - people are often forgetful, lazy or forget
to update prior to commit etc whereas a machine is far more consistent.
Trusting the developer to do this also creates an extra burden on them
which could be spent doing other things (like coding).

Nick