Whole tree up to date before committing

[Tom Widmer]

Óscar Fuentes wrote:
> "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

Only if he wrote it down or put it in his commit message or similar - I 
don't think Subversion has the first clue what revision any uncommitted 
files were at locally when a historic commit happened.

You can note the version you had checked out when you run the test suite 
in Bazaar as well (enforce putting it in your commit message if you like).

Tom