Re: [tlug] Re: Call for presenters - March 14th technical meeting

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > While of course either can be used either way, I've noticed a strong
 > preference for projects using distributed VCSs to do centralized
 > merging, whereas projects using centralized VCSs have a possibly even
 > stronger preference do distributed merging.

The difference is that projects using DVCSes use the VCS to do
merging, and have the option of doing it centrally.  Those using
legacy VCSes have no choice but to insist that the developers do the
merging, not the VCS.

This may be changing in recent Subversion, but the jury's out on that.

 > So I'm not even sure the labels are accurate.

That depends on what you mean.  "Distributed" and "centralized" are
not antonyms, though.  "Distributed" vs. not refers to where commits
take place.  In a DVCS you have the option of "all over hell and
gone", in a legacy VCS you don't.  "Centralized" refers to whether you
have to push to communicate your changes to others or not.

Both terms also apply to workflows.  Typically the problem is that
people confuse VCS (infrastructure == possible workflows) with
workflow (== politically mandated).

 > There are obvious examples: in Linux (distributed VCS) all of the
 > (official) kernel changes go through one or a few people,

Have you browsed git.kernel.org recently?  Linus's tree is the tip of
the iceberg and all that.

 > whereas in NetBSD (centralized VCS) there are several dozens of
 > people who regularly commit to various areas of the kernel.

And of those several dozen, how many have an URL to their current
active repo that you can post so that I can pull from it?