6 ms·

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.

• axod 17y ago
  It's funny how it's usually easier to ditch X, and write Y from scratch, rather than try to improve X.
  • Jasber 17y ago
    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.
    • mechanical_fish 17y ago
      Yes, where by "baggage" you mean "vitally important existing customers, users, and dependencies that will break if you change anything".
      • Jasber 17y ago
        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.
    • jmaygarden 17y ago
      Case in point: Blockbuster versus Netflix http://www.onlykent.com/20100318/blockbuster-bankruptcy-2010-latest-news-and-shares-drop/ http://www.onlykent.com/20100318/blockbuster-bankruptcy-2010...
  • dschobel 17y ago
    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.
  • roc 17y ago
    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.
• graywh 17y ago
  Joel doesn't just say that SVN is obsolete; he compares it to a blood-sucking worm. That's some strong emotion.
  • dschobel 17y ago
    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).
  • mgrouchy 17y ago
    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...
    • rue 17y ago
      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 :)
• ssp 17y ago
  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).
• pingswept 17y ago
  That first blank will be filled with "suck!"