Subversion developer: svn is for dumb people

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

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

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

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.

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                                                [email protected]
OOO                                                http://www.madism.org

Hi,

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

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                                                [email protected]
OOO                                                http://www.madism.org

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
[email protected]