Richard Wackerbarth writes:
Having a main branch implies that the organization is imposing its idea of "the right way".
In some sense true, but few organizations have either the resources or inclination to maintain and support more than one "right way" at a time.
History shows that parts which once were considered "the main branch" often become byways as the momentum of the flow embraces new ideas, directions or leadership.
Are you implying that bzr isn't capable of recognizing that a new branch has become the mainline? That's false, you know. Any head in your workspace can become mainline, and any commit can sprout a new head. (It's true that it requires substantial effort to change the *public* mainline, but that's true of all DVCSes, including git: this is a consequence of the same underlying issue that we know as "the rebase problem".)
The rule in bazaar is actually the same as in git: the sequence of leftmost ancestors of the current checked-out head appears as mainline. The difference is that by default "bzr log" will hide non-leftmost ancestors of merge commits, thus emphasizing the mainline, and this behavior is part of the specification of bzr.
This is very compatible with the project workflow Barry expressed a preference for: the mainline appears as a sequence of merges of feature branches. However, bzr is perfectly compatible with much less elegant workflows, such the use of bzr to emulate CVS. ;-)
In any case, Mailman is not going to change VCSes any time soon, and if you prefer to use git or hg, bzr supports the fastimport format for export and import.