No subject

>>>>>>>>>>>>>>>>>
In fact, Bazaar is 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? It’s all part of our philosophy that
the trunk ought to be ready to ship all the time. Used intelligently
with automated testing, Bazaar can help keep the quality of your trunk
as high as possible.
<<<<<<<<<<<<<<<<<<

I don't see this as an advantage, quite the contrary. On mildly active
projects one could find himself doing a merge after another, without a
chance for committing. Think about projects with about 300 commits every
day during working hours coming from 50 developers, with most commits
concentrated on the last hours of the journey. Bazaar's model would be a
serious annoyance there. Moreover, not being allowed to commit a change
because someone modified a totally unrelated part of the project is one
reason for labeling the tool as "stupid".

I'm not saying that Bazaar's policy, if applicable, isn't better than
subversion's. My point is that on some common scenarios creates more
trouble than it solves.

Besides, I think that claiming that Bazaar enforces some philosophy
contradicts previous claims about its flexibility. Its good that
Bazaar's developers try to keep the project on shippable state all the
time, but other teams may have their own ideas about that. Certainly,
most projects begin their lives on a non-shippable state :-) Your claim
about bzr enforcing good policies looks to me like the old trick of
"it's not a bug, it's a feature".

-- 
Óscar