Whole tree up to date before committing

Óscar Fuentes ofv at wanadoo.es
Thu Oct 22 18:55:01 BST 2009

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> So then don't use bound branches, use an alternative workflow.

As mentioned on my other reply, distributed workflows suffer from the
same, once you have lots of developers trying to incorporate their
changes into the same branch (i.e. the master, "gold" one).

> If you have a better way to to make the point than Ian's, cool, but
> note that the point that he's trying to make is that *bound branches*
> are stricter about this than svn, *if that's what you need*.

Nope, there is no way around this enforcement, so you must abide to it
too when you don't need it. (And even when it is a nuisance.)


>     In fact, if you are serious about keeping the trunk pristine,

I'm serious about keeping the trunk pristine. I'm serious about
productivity too, which is a larger view of the issue.

>     Bazaar supports workflows that are stricter about centralized
>     development than Subversion. Subversion will only check that
>     changed files are up to date locally while Bazaar will ensure your
>     whole tree is up to date before committing to a *bound branch*. Why?
>     If your philosophy (like ours!) is that the trunk ought to be ready
>     to ship all the time, then used intelligently with automated testing
>     Bazaar's *bound branches* are one way to help keep the quality of
>     your trunk as high as possible.

Even discarding my observation about distributed workflows being
equivalent to centralized ones wrt this topic, the honest wording would
be: using bound branches forces a check that insures that your whole
tree is up to date before you can commit your changes. This has the
advantage of lessening the chances of a broken build, but may create a
bottleneck when several developers commit their changes within a narrow

> work for you?  (IMHO before offered for general consumption, it needs
> some TLC from the Sleazy Marketroids, my phrasing is a little
> condescending,

Yes, it is :-)

One project where I partipate has about 20 daily committers, which
combined make an average of about 100 commits per day. Most of them
work on the same timezone, so commits tend to concentrate on the same
hours. As they are serious about keeping the build pristine, a full
`make check' is mandatory before committing code changes (let's say
there are 60 of those per day). Building the project and running the
test suite takes about 20 minutes on a state-of-the-art workstation. I'm
sure you will realize that bazaar's policy will create a so serious
bottleneck that is inapplicable.

That project relies on a series of buildbots that continuously runs on
all supported platforms. After all, `make check' working on the
developer's machine does not mean that it works on other's.

So you will realize the implications of bazaar's policy: creating a
serialization of the commits which is unacceptable on some common
projects, and this is the reason why other VCSs does not inforce
it. Adding an option for disabling that policy would make a lot of



More information about the bazaar mailing list