Whole tree up to date before committing

[Óscar Fuentes]

Nicholas Allen <nick.allen at onlinehome.de> writes:

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

We have an automated system. But the vast majority of build problems are
caught by the local test performed by the developer.

> It would also free the developer from doing this
> so make him more productive. So you get higher productivity and more
> stability.

Waiting hours for knowing if a patch breaks the build doesn't look very
productive to me.

While I'm running the test suite on my local machine before committing,
I usually work on another working tree doing other stuff.

[snip]

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

Yes, svn can be configured to produce log entries for operations such as
update and commit. Here is an excerpt:

[23/Oct/2009:10:29:54 +0200] 200 joe 192.168.1.9 commit r386
[23/Oct/2009:10:31:46 +0200] 200 jim 192.168.1.10 update /trunk/foo/bar r386 depth=infinity

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

It happens from time to time (once per month for us). Less frequently,
not using file locking introduces very nasty errors while resolving
conflicts. But we assume this cost, as using file locking would damage
overall productivity.

You insist on "whole tree up to date" as if it were a definitive recipe
against inconsistency. It isn't. In the end, everything is about
trade-offs.

-- 
Óscar