That's just life in technology as the tools improve.

1) Stop manually backing up versions, that's error-prone. Use RCS!

2) Stop using RCS, it doesn't scale. Use CVS!

3) Stop using CVS, it's too complicated. Use SVN!

4) Stop using SVN, it makes it hard to merge branches. Use Hg/GIT!

... And someday, we'll be saying 5) Stop using Hg/GIT. They ________. Use _______!

Same thing for hardware, and languages, and frameworks... and just about everything. shrug

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).

"stab SVN/CVS in the back"???

I'm not sure why you're borrowing an assassination metaphor to describe someone's shift in technology choices. Technology aren't people.

Would you rather I'd said "throw X under the bus"?

No one has to be executed here. How about "start using a different tool"?

It really still depends on your use case. At my day job I advocated switching from SVN to HG and the change has been great - now we "branch" and merge constantly and it really helped our processes. On my iPhone game at home I still use SVN with beanstalk.com and it works great.

Old technology that has been surpassed should be stabbed in the back. That doesn't mean the old technology can't be appreciated, just that it's place in the world has changed.

Nobody is driving 55 Chevy's around anymore. Some people dedicated aspects of their lives to appreciating the time and space when that technology was dominant, but their glory days have passed.

So has subversion's.

It is great, but I actually think it's a little unfair. CVS was better than directories with date suffixes, and SVN was better than CVS. Git sounds better than SVN.

But to me, SVN isn't one of those technologies that I'll look back on and despise. Sometimes you look back on a technology and wish it had never existed (the original EJB seems to inspire this in some people), sometimes you look back on it and see deep flaws but still have respect for it as a first crack at a problem (some people look on the original Struts framework this way), and some you look back on fondly even if you no longer personally use it (a lot of ruby/python folks seem to look back on perl this way).

To torture the analogy, I'd say SVN is a moderately effective antibiotic that has been replaced with a more effective one that has fewer side effects. But a leech? Come on, it was a good technology.

Such is the life of hipsters.