Why Subversion is better than Git

The big advantage of branches is to allow to break your commits into smaller things. When working on two new features which takes many commits, if you work on the same branch, the history becomes inter winded, and that's a nightmare to understand if you need to go back (or find regression). With branches that are pulled into a public reference branch, you are guaranteed to get a workable, coherent and consistent state. Without branches, what happens is either broken trunk or giant commits, both often worse than the (real) complexity brought by branch.

The fact that DVCS allows for less rigid management alo explains why DVCS became popular so quickly in open source, I think (where the kind of collaboration managements you suggest does not scale very well).

Not necessarily so. As I said, my experience may not be representative of the most common workflows, but in the company I'm working for people often work on experimental or tangential stuff but at the same time they want their changes to keep pace with the work on the main line. I that case they can't afford to sully the trunk and at the same time, because merging back a branch is a major pain, they can't fork off a branch, unless it is a significant enough chunk of functionality or code they are changing. No amount of "collaboration management" is going to make the situation any better, because all options result in some amount of pain for someone, pain makes people touchy, and touchiness makes people not work together properly.

Just as you believe that a proper social structure and sufficiently clear conventions can overcome deficiencies in software, I believe the oposite - the capabilities and limitations of software can enforce certain patterns of behavior. And in my experience DVCSs end up having more of a positive effect on the development process.

I use branches in Hecl to play around with experimental features. These are things that I want to keep around for a while, hack on, but that are not ready to be in Hecl proper. If I had to wait for a yes/no on those features to go on with other things, it would slow things down.

"I want 1 codebase, developed linearly."

Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end.

Except you can trivially have multiple of these things going at a time.

I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git might affect workflow to people who actually know how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)

Before 1.5, svn had no real merge capability. In particular, it could not detect that you merged something already when merging a changeset. Also, the merge command effectively "squashed" everything - you could use svnmerge and co to get something a bit better, but the tools were very poor to say the least.

Technically speaking, svn merge is more akin to cherry-pick in git/hg/etc..., where the "merged" commits are not recorded as such, but as totally new commits.

Note also that bad svn merging capabilities are specific to svn, not to centralized VCS (perforce, etc...). It is not so much that DVCS are better than svn as much as svn worse than everything else.