Whole tree up to date before committing

[Óscar Fuentes]

"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 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 :-)

-- 
Óscar