Whole tree up to date before committing

[Nicholas Allen]

> We have an automated system. But the vast majority of build problems are
> caught by the local test performed by the developer.
>   
Why not make your make check step automated as well and free the
developer of this burden? You could also have 2 gatekeepers - one where
you know make check works and another where all tests pass.
> Waiting hours for knowing if a patch breaks the build doesn't look very
> productive to me.
>   
You don't need to wait. Get on working in your own trunk, feature or
addition branch without distractions in the meantime.
> While I'm running the test suite on my local machine before committing,
> I usually work on another working tree doing other stuff.
>   
You can also do this while waiting for the gatekeeper to merge your
changes. I'm not sure I see your point here.
>
> 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
>   
Ok but that sounds like a lot more hassle. Wouldn't it be better if you
didn't need to do that in the first place?

> 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.
>   
I'm suggesting a gatekeeper and private branches for developers which
would give you consistency.

The update before commit would give you at least as much consistency as
you currently have with subversion - which you say you are happy with.

A simple script in Bazaar would do the update for you before commit.
Personally I would never use such a script but if you really want to
recreate the exact way of doing things as you currently do with svn you
can do so like that.

I just think it sounds like a different workflow, enabled by Bazaar,
would better suite your development team. Bazaar doesn't force any
particular workflow on you so choose whatever you feel to be the most
suitable. If you feel the current workflow is the best for your team
then stick with that - Bazaar doesn't stop you.

Cheers,

Nick