Whole tree up to date before committing

[Óscar Fuentes]

"Matthew D. Fuller" <fullermd at over-yonder.net> writes:

> On Fri, Oct 23, 2009 at 03:43:42AM +0200 I heard the voice of
> Óscar Fuentes, and lo! it spake thus:
>> 
>> The problem is that, on the project I'm talking about, there is a
>> policy that requires that you can't commit changes to the master
>> branch (trunk) without checking that it builds and running the test
>> suite.
>
> But, you're ending up with the exact same result as you have now with
> svn.  You mean that just because the dev actually RAN update and
> nothing conflicted, as opposed to the VCS internally seeing that
> nothing conflicted and doing its own in-memory pseudo-update, the
> dev's burden changes?

You have a point here. The issue is more related to psychology and
policy enforcement than to anything else.

The developer is required to do everything that is within his reach to
avoid putting the project on a broken state. 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. We can know which subversion rev number that developer had on his
machine when he committed, 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.

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.

[snip]

-- 
Óscar