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. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
