[Mailman-Developers] [Merge] lp:~wacky/postorius/csrf into lp:postorius

[Barry Warsaw]

Okay, you get the last word too. :)

On May 21, 2012, at 06:32 AM, Richard Wackerbarth wrote:

>On May 19, 2012, at 9:26 PM, Barry Warsaw wrote:
>> While I really don't want to get into yet another religious VCS discussion
>> on yet another unrelated list <wink>, Bazaar has one killer feature IMO
>> that neither hg nor git has.  (There are many things I prefer in bzr over
>> hg and git, but this is the big one).
>> 
>> Bazaar has a strong concept of a 'mainline' branch.
>
>I can argue that this is also a weakness. The tool is imposing management
>practices on the users.  In a current sense, conventions are equally capable
>of designating the mainline.  In a historical sense, the mainline only
>indicates the order of "approval".

Note that 'mainline' does not mean 'blessed master branch'.  Conventions
surely do designate the latter.  Someday when y'all revolt against me, you can
all agree that lp:mailman is no longer the blessed master branch.  Hey, that's
FLOSS.  But I still think that within a single branch, it's useful to have a
main line of development, and I think that jives with most people's intuition
about software development.

The really important concept I think is that merges are first class events on
a particular branch, represented by their own single revision within the
history.  These merge revisions can be expanded for more detail, where all the
gory details of its history are revealed, letting you choose to care or not
care about it.

>Having a main branch implies that the organization is imposing its idea of
>"the right way".
>
>It is somewhat like the Corp of Engineers telling a river how it should
>travel through its delta region.
>
>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.

Most feature and bug fix branches are quite short lived.  They rarely become
the heads of long lived lines of development.  There are other ways to handle
the conventions that lead to more sweeping changes of focus, and I don't think
there's much of a difference in how the dvcs's handle that.  There may be ways
in which the code hosting providers do better or worse ways of managing that,
but it seems independent of the lower-level dvcs.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120521/25e2912e/attachment.pgp>