On Thu, Oct 18, 2007 at 07:25:36AM -0700, Steven Grimm wrote:
> Okay, my summary is slightly facetious, but that's basically the gist of
> what he's saying: you should choose Subversion rather than a DVCS because
> most of your users won't be smart enough to use the better tool.
An interesting point he brings up (which I think is totally bogus) is
(paraphrased): "DVCS systems encourage people to work in isolation and
then patch-bomb the upstream."
But I think it's quite the opposite. He compares two scenarios: in
$DVCS, the user forks, works quietly in their cave for a few weeks, and
then produces a result. With a centralized VCS, the user gets a private
branch, and people keep up with their work as it progresses.
This isn't realistic for two reasons:
1. Contributors to projects now using DVCS systems _weren't_ using SVN
or CVS in this way before (presumably because the effort in getting
private branches set up in a central repository was too much -- if
I want to hack on a project, I want to do it _now_, not after I
have gotten approval to use the VCS by the maintainer). Instead,
they sat in their cave using primitive tools like 'diff' and
'patch' until they patch-bombed the upstream.
2. DVCS systems (well, git, at least) focus on workflows that allow
for quick communication and code review. Patches are a first-class
item in git, which means that
- every change is on the mailing list for review
- work-in-progress patches are easy to post, easy for reviewers
to read, easy for reviewers to apply, and, if accepted,
easy for the maintainer to apply
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
