Whole tree up to date before committing

[Óscar Fuentes]

Ian Clatworthy <ian.clatworthy at canonical.com> writes:

[snip]

> 1. Make a change. Run local tests. Commit. If the commit fails because
>    the tree is out of date, the developer can make a judgement call as
>    to how important it is to run the tests again before re-trying
>    the commit. In my experience, Bazaar will fetch the latest tip
>    pretty quickly and there are rarely conflicts, so that isn't a
>    bottleneck unless the commit frequency is over 20-30/hour[*], say.
>    Most developers also know their code base well enough to know whether
>    another change could impact theirs or not. People are human though so
>    the buildbot remains an important component of any serious QA effort.
>    In fact, the higher the commit frequency, the greater the risk of
>    instability so discipline and automated testing only increase in
>    importance IMO.

Code changes without building and running the test suite are
forbidden. Period.

Too often I judged a change trivial, commit it and later had to confront
some angry fellows. Maybe a full build can be avoided if the change is
very localized, but I would think thrice before committing without
running the test suite.

So the workflow would be:

 1. Re-build and run the test suite. This will take 20 minutes on a
 fast Linux machine, 1 hour on a fast Windows machine. Meanwhile, work
 on something else using other local feature branch.
 2. If okay, re-sync my local branch with master and see if this
 introduces code changes.
 3. If yes, go to step 1.
 4. Push to master.

[snip]

> FWIW, I frequently mix-and-match centralised and distributed workflows.
> On 90% of my projects on Launchpad, my trunk is a bound branch and I
> make small bug fixes directly there. For new features or complex bugs,
> I'll create a feature branch, work there and merge back into trunk when
> it's ready. I find this work pattern really productive myself.

Same here. I really appreciate bzr flexibility here. It was surprising
to me fo find that bzr *imposes* the "whole tree up to date" policy. I
guess that supporting the "file up to date" policy is complex.

[snip]

> [*] I believe your team is making 100 commits per day and many of them
> are small. I wonder how many of those would become commits on a feature
> branch if larger items (both features and bugs) were developed that way?

As I mentioned elsewhere, commits for small bugfixes and tiny
improvements are common. No doubt that feature branches would be useful
here, and I miss them very badly, but they wouldn't decrease commits to
master enough to avoid the bottleneck.

-- 
Óscar