Whole tree up to date before committing

[Nicholas Allen]

>
> The developer is required to do everything that is within his reach to
> avoid putting the project on a broken state.
I'd say an automated system would be better and more consistent at doing
this than a developer. It would also free the developer from doing this
so make him more productive. So you get higher productivity and more
stability.

You can design your test suite in such a way that it can be run in a
distributed manner if it's really not possible to process a day's
requests in a 24 hour period. I would find this unlikely though because
PQM can run all through the night while developers are not working. Also
your current system needs to run against revisions that have been
committed and so it wouldn't be able to keep up otherwise.
>  If he commits code and
> breaks things, saying "I really tested the change, but it was before
> updating my local copy" would sound as a lame excuse. If this is
> tolerated, it opens the door for irresponsible people not checking at
> all.
You're saying it is tolerated in your svn workflow unless I misunderstood.
>  We can know which subversion rev number that developer had on his
> machine when he committed, 
How can you know that? I didn't think svn recorded this information. If
the user has done an update since his commit there is no way to tell
AFAICR (but maybe subversion logs this somewhere in the repository and
I'm just not aware of it). Again I appologize if this is just svn
ignorance on my behalf.
> and if things go really hot, we can test his
> changes based on that revision (remember: breaking the build or making
> changes that breaks the test suite is considered more antisocial than
> spitting on somebody else's soda). But with bazaar, everything we know
> is that he must had the latest revision before committing.
>   
That's a good thing.
> I agree that, technically, the difference among whole-tree and per-file
> up-to-date-before-commit would only matter on very large projects, if we
> leave aside scenarios like the described above.
>   
If I understand you correctly you are saying that there are so many
commits happening at such a fast rate that a developer would have
difficulty committing his changes as he would have to keep updating due
to someone else getting in before him. In subversion it would just allow
it anyway. If this is really the case then the trunk will get seriously
unstable due to so many small changes not being tested together. It
sounds like a recipe for instability to me.