RCS, CVS and SVN are in a real sense the same thing. You can view CVS as fixing a bug in RCS (it doesn't have concurrency), and SVN as fixing bugs in CVS (it doesn't have atomic commits). That is even how the SVN developers themselves marketed it.

Hg and git are different. It's not like SVN has a bug "it isn't distributed". It is fundamentally not distributed. So the progression is:

1. Stop manually backing up versions, it sucks. Use RCS/CVS/SVN.

2. Stop using RCS/CVS/SVN, they suck. Use git/Hg.

I can easily imagine a new DVCS system that would fix bugs in git or Hg. The git UI sucks for example. But I can't easily imagine a fundamentally different successor to DVCS.

(Not that such a successor won't happen - of course it will. I just can't imagine what it will look like).

It's funny how it's usually easier to ditch X, and write Y from scratch, rather than try to improve X.

I agree and don't think it's limited to programming. Considering business, it's difficult for a large established organization to make drastic changes.

It's much easier for a new entrant (startups) to innovate because they don't have the same baggage.

Yes, where by "baggage" you mean "vitally important existing customers, users, and dependencies that will break if you change anything".

Yes, I do.

But that doesn't change my statement.

If you're not willing to break your business to change with the times, someone else will--and by the time you react it's too late.

Case in point: Blockbuster versus Netflix

http://www.onlykent.com/20100318/blockbuster-bankruptcy-2010...

I think this affects version control systems specifically because the nature of the beast is to create a format to track changes over a long period of time. Changing that format is a huge pain in the ass and rarely worth it.

In VCSes more than in regular software, you really have to get the design right very early in the process.

When an improvement comes from a new mental model of the data/problem, it's at least as much work to fix X as to write Y from scratch. Generally much more, as you must figure out how/whether to interface old features to the new model.

Similarly, in the case of changing mental models, most users and even developers of X won't be ready for Y when you write it. Trying to force the change onto those people will harm X and handicap acceptance of Y by confusing the Case For Y with the Case Against Killing X.

So it's hardly surprising.

That first blank will be filled with "suck!"

Joel doesn't just say that SVN is obsolete; he compares it to a blood-sucking worm. That's some strong emotion.

or he is just making a comparison of how before antibiotics one may have used leeches to try to rid themselves of sickness, but using leeches became obsolete(mostly) after the rise of antibiotics...

Though it turns out leeches are actually useful for modern medicine too. Being mean, I would say that is where the analogy to SVN breaks :)

That was't he point of his metaphor, the point was about a massive step forward in technology.

The full quote makes it clearer:

"Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now." (emphasis his).