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 12:38:18AM +0200 I heard the voice of
>> Óscar Fuentes, and lo! it spake thus:
>>> I repeat that bzr policy is the right one, but it cannot be applied
>>> to some projects, so subversion's model is a reasonable trade-off.
>> That's not really the case, though.  The developer (when told he needs
>> to 'update' before commit) runs 'update'.  This takes a few seconds.
>> If there aren't any conflicts, he can just commit, and he'll be in the
>> same place as he was with svn; it may be broken due to those outside
>> changes, but that's the case now.  If there WERE conflicts...  well,
>> he'd have had to deal with them in svn too.  Commiting takes a few
>> seconds longer, on waiting for update, but the dev also has a chance
>> to eyeball the list of changed files and have a offhand guess as to
>> whether it needs a closer look before commit.
> 
> 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. After
> testing your changes and re-synching your local branch with master, even
> if there are no conflicts, your code is not what you tested before, but
> something else, so you need to test again, and in the meanwhile someone
> else will push something into the master branch.
> 
> The seconds that bzr requires are not the problem, re-building and
> testing is what creates the problem.

But enacting your policy requires different commands in Bazaar vs 
Subversion:

SVN:
make changes
loop [
   svn update and handle any conflicts
   run test suite
   svn commit
   if (commit succeeded) return
   else loop
]

BZR:
make changes
loop [
   bzr update and handle any conflicts
   run test suite
   loop [
     bzr status //note which files you've changed
     bzr update
     if (no changed files were updated)
       bzr commit
       if (commit succeeded) return
       else loop
     else
       break
   ]
]

The problem is determining "if (no changed files were updated)", and I 
don't know how to do that beyond comparing the output of bzr status and 
bzr update - perhaps someone else has an idea?

That way you've always run the test suite against integrations to files 
you've changed in your commit, which matches your Subversion policy. But 
you've chosen your Subversion policy purely because that's what the tool 
makes easy - in Bazaar, you have more options.


> But now that you mention it: on very large projects with lots of
> developers (think on KDE) even the short time bzr requires may be a
> problem. On that scenario, be sure to write your commit message before
> updating your local branch, because if you are a slow typist, maybe your
> commit window is gone when you finish :-)

Then you just update and recommit (using the same message). But having a 
very large number of developers committing to a single branch using any 
VCS is probably asking for trouble - the linux kernel style hierarchal 
pulling approach might work better.

Tom