Subversion developer: svn is for dumb people

Subversion developer: svn is for dumb people

[Steven Grimm]

Thought folks here might get a kick out of this:

http://blog.red-bean.com/sussman/?p=79

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.

I can't say he's completely wrong, especially about the 20/80% idea 
(though I think "20%" is generous), but some of his specific arguments 
about DVCS are on the bogus side. "Centralized systems encourage code 
reviews," for one -- I challenge him to find a project with a more 
pervasive and effective code-reviewing culture than the git project. I 
find code reviews *harder* in a centralized system because you end up 
building external tools to help people try out each other's changes.

-Steve

Re: Subversion developer: svn is for dumb people

[David Brown]

On Thu, Oct 18, 2007 at 07:25:36AM -0700, Steven Grimm wrote:

> I can't say he's completely wrong, especially about the 20/80% idea (though 
> I think "20%" is generous), but some of his specific arguments about DVCS 
> are on the bogus side. "Centralized systems encourage code reviews," for 
> one -- I challenge him to find a project with a more pervasive and 
> effective code-reviewing culture than the git project. I find code reviews 
> *harder* in a centralized system because you end up building external tools 
> to help people try out each other's changes.

The review comment is completely bogus.  Centralized systems, at least like
SVN and P4 encourage a check-it-in-deal-with-the-problems-later attitude.
The tool discourages you from trying out other's changes, whereas a DVCS
tends to have lots of little branches and easy migration between them.

I think this is less an issue of distributed or not, but more that branches
are just so expensive in most other revision control systems.  Whether that
is expensive in resource, or just in understanding what is going on (for
example, requiring users to track merge ancestors is rediculous).

David

Re: Subversion developer: svn is for dumb people

[Jeff King]

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

Re: Subversion developer: svn is for dumb people

[Sam Vilain]

Steven Grimm wrote:
> some of his specific arguments
> about DVCS are on the bogus side. "Centralized systems encourage code 
> reviews," for one --

I heard this from the core Subversion team too.  The hypothesis is that
by forcing groups to be unable to proceed without continually rebasing
to each other's work, that collaboration is enhanced.

I think any argument which states that a restrictive system is better
than a non-restrictive system, when the non-restrictive system can be
used in the same way as the restrictive system (either with
configuration, or agreement with the committers) is quite bizarre.

Sam.

Re: Subversion developer: svn is for dumb people

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

On Thu, Oct 18, 2007 at 02:25:36PM +0000, Steven Grimm wrote:
> Thought folks here might get a kick out of this:
> 
> http://blog.red-bean.com/sussman/?p=79
> 
> 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.
> 
> I can't say he's completely wrong, especially about the 20/80% idea 
> (though I think "20%" is generous), but some of his specific arguments 
> about DVCS are on the bogus side. "Centralized systems encourage code 
> reviews," for one -- I challenge him to find a project with a more 
> pervasive and effective code-reviewing culture than the git project.

  Your argument is also bogus.

  IMNSHO, peer reviewing has nothing to do with git, svn, or $SCM. It's
a social pattern. There are people that do it because they understand
it's a good and necessary sound thing to do, and there are the others.
Guess what, it has a lot to do with the 20%/80% line (that I would have
more described as the 2/98 but well…).

  Put git into the hands of fools, they won't proofread their code more
or less than with svn. And they will shoot themselves into their foots
twice as often as with svn.

  Though, for people that are able to deal with git and use it, git
allows way better code reviewing patterns than with svn, because you
can prepare a nice incremental branch that adds each new features you
worked on with small patches (see my parse-options series). With svn,
you can't do that, because there is no tool that allow you to record
those patches on your end, so you submit a big +4123/-2341 patch. That
makes peer reviewing really harder.

  Of course the git community is a perfect example of how code should be
reviewed. But it's not because we use git, it's because we definitely
are in the "20%".

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Subversion developer: svn is for dumb people

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1726 bytes --]

Hi,

On Fri, 19 Oct 2007, Pierre Habouzit wrote:

> On Thu, Oct 18, 2007 at 02:25:36PM +0000, Steven Grimm wrote:
> > Thought folks here might get a kick out of this:
> > 
> > http://blog.red-bean.com/sussman/?p=79
> > 
> > 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.
> > 
> > I can't say he's completely wrong, especially about the 20/80% idea 
> > (though I think "20%" is generous), but some of his specific arguments 
> > about DVCS are on the bogus side. "Centralized systems encourage code 
> > reviews," for one -- I challenge him to find a project with a more 
> > pervasive and effective code-reviewing culture than the git project.
> 
>   Your argument is also bogus.
> 
>   IMNSHO, peer reviewing has nothing to do with git, svn, or $SCM. It's 
> a social pattern. There are people that do it because they understand 
> it's a good and necessary sound thing to do, and there are the others. 
> Guess what, it has a lot to do with the 20%/80% line (that I would have 
> more described as the 2/98 but well…).

I tend to disagree.  Git at least _enables_ you to have the 
one-committer-per-repository scheme, it even _encourages_ it to a certain 
extent.

And once you go that route, it is easy to see that the committer says "I 
will not let that _crap_ enter my repository."  Bingo, peer review.

Compare that to a centralised repository, where more often than not, the 
administrator is not even part of the developer community!  It is much 
easier not to feel too responsible for the code you are committing there.

Ciao,
Dscho

Re: Subversion developer: svn is for dumb people

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

On Fri, Oct 19, 2007 at 01:17:05PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 19 Oct 2007, Pierre Habouzit wrote:
> 
> > On Thu, Oct 18, 2007 at 02:25:36PM +0000, Steven Grimm wrote:
> > > Thought folks here might get a kick out of this:
> > > 
> > > http://blog.red-bean.com/sussman/?p=79
> > > 
> > > 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.
> > > 
> > > I can't say he's completely wrong, especially about the 20/80% idea 
> > > (though I think "20%" is generous), but some of his specific arguments 
> > > about DVCS are on the bogus side. "Centralized systems encourage code 
> > > reviews," for one -- I challenge him to find a project with a more 
> > > pervasive and effective code-reviewing culture than the git project.
> > 
> >   Your argument is also bogus.
> > 
> >   IMNSHO, peer reviewing has nothing to do with git, svn, or $SCM. It's 
> > a social pattern. There are people that do it because they understand 
> > it's a good and necessary sound thing to do, and there are the others. 
> > Guess what, it has a lot to do with the 20%/80% line (that I would have 
> > more described as the 2/98 but well…).
> 
> I tend to disagree.  Git at least _enables_ you to have the 
> one-committer-per-repository scheme, it even _encourages_ it to a certain 
> extent.
> 
> And once you go that route, it is easy to see that the committer says "I 
> will not let that _crap_ enter my repository."  Bingo, peer review.
> 
> Compare that to a centralised repository, where more often than not, the 
> administrator is not even part of the developer community!  It is much 
> easier not to feel too responsible for the code you are committing there.

  I agree, that's why I said that git made it easier. WHat I pretend to
be wrong is to say that a SCM will make people review code or not. Git
merely help people that want to always review code to be completely sure
some review has happened before the code is merged. But nothing in git
forbids you to use the big fat <centralized repo with everyone having
push access to it>-mode.


-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Subversion developer: svn is for dumb people

[Andy Parkins]

Steven Grimm wrote:

> find code reviews *harder* in a centralized system because you end up

I think I'd argue that git actually reduces the problems of patchbombs
(which is a code-review problem).

Those who are going to patchbomb will do it whatever their VCS choice (and
I'm not entirely convinced that patchbombs are as bad as is made out in
that article).  With a centralised VCS the patch almost has to be one giant
diff - very hard to read and review.  Git, on the other hand, allows the
patchbomber to work alone crafting not only beautiful code, but a beautiful
patch series.  The bomb can be easy to review, easy to reject, and easy to
modify.  It becomes far more likely that the code can be used in some way.

I guarantee that the only reason I ever contributed anything to git itself
was because the bureaucracy line is so low - and it is low because of git.

Key features for a DVCS from a newbie point of view:
 - Making a fool of yourself can be done in private rather than in public.
   I have loads of branches in my git repository that I will never submit,
   because they were the beginnings of ideas that didn't pan out (and I'm 
   lazy)
 - You don't need _any_ permission to fork/branch.
 - You can work away on your feature without worrying too much that time
   has passed and the main project has moved on and you aren't keeping up
   to date.  I've got a set of patches for git (the REF_PATHS stuff) that I
   started a year ago.  I recently rebased it and brought it up to date.
   It's still not in mainline, but I'm not panicking, nor do I have to
   abandon it because it's so easy to catch up whenever I want to.
 - I can work on two features simultaneously.  If I have two ideas - crazy
   and safe, both independent, I can work on both without having to mix
   them for the day when I submit.  This makes it a lot easier to keep them
   on the go, and a lot easier for the maintainer to decide what goes in and
   what doesn't.
 - The ability to craft a log messages that are kept locally and easily
   edited before submission goes a long way to helping cross the
   brave-enough-to-submit barrier.  Presenting new code as an unknown
   developer on a project is (I think) quite a stressful thing.  Git let's
   you feel as prepared as you want before you take that leap into having
   your code ripped apart.

In short: those pro-centralised arguments are nonsense.  Even if they
weren't the advantages of DVCS heavily outweigh the advantages of CVCS.



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com