The design roots of Subversion can be traced back to the first very simplistic attempts at version control, such as SCCS and RCS. The design of it has steamrolled on from the 70’s with little consideration of stable internet development methods practiced since at least the mid-eighties.
The claim is made that Subversion “just fixes CVS”. And while Subversion is generally more robust and versatile than CVS, some still see it as a step backwards. Unlike CVS, SVN is hard to fix when it goes wrong - there are no user-servicable parts inside. Branches and even tags are denied first class recognition by the system, no doubt borrowing some design from Perforce but missing the important bit that made it work (p4’s integration - only now being added with “merge tracking”). CVS fixed? Hardly - CVS re-engineered as a cripple. (For a true “drop-in” replacement for CVS that fixes the most important bugs of CVS and doesn’t remove features, try git-cvsserver)
Don’t buy the “svn 1.5 will fix merging” snake-oil; the new design is still vastly deficient compared with the real A-class tools out there today, such as Git, Bazaar-NG and Mercurial. It might be almost as good as Perforce, hooray you’ve caught up to 10 years ago. That’s if we ever see a release - since last November, the Subversion team have managed 6 minor releases, compared to git’s 1 major release, 3 minor releases, 30 stable releases and 26 stable release candidates. There really is no comparison.
As for the speed, after using Git or Mercurial for a while, you go back to SVN and you seriously start to think it’s broken or hung - then you realise no, it’s just slow. Especially if you are trying to treat your code as a revision data warehouse, for techniques such as code annotation or bisection.
As far as “using HTTP infrastructure” - this is an oversold benefit - note that Subversion is actually using HTTP+WebDAV as a horrific delivery mechanism for its XML-RPC messages. There’s nothing standard about it at all - and that’s ignoring the fact that WebDAV required us all to upgrade our webservers. Some users were forced into an upgrade treadmill to install the specific, alpha version of Apache that was required.
By my own observation, virtually every proponent of Subversion left either has a significant stake in it, or has simply never tried any other system. They are in another world - a world where removing the ability to do sane branching, merging and tagging was construed as a feature. The net effect is that the open source community is now left with a legacy of useless history for the 5 years or so that the SVN fad has taken the world by storm. This legacy is not caused by the difficulty in conversion - not at all - but more from the dreadful development practices its idiotic design promotes. The buzz word of “commit bit” disguises a widespread practice of skimping on code review. Sure, it might be possible to figure out what the individual changes are in that repository, but who can dig them out from the mess of commits? And with sufficiently few eyeballs to review changes, all code bases are buggy.
And buggy it certainly is. Virtually every project I encountered that tried to use its API - assuming they could figure its crazy system of batons and allocation pools and callbacks out - were mired with random segfaults and difficult to track down core bugs.
Subversion has already become a modern relic; it’s a zombie project unable to make stable releases or effectively manage their spaghetti codebase. Abandon ship now.
(NOTE: not that I don’t have some good things to say about it, see for instance use perl article on subversion (search for “What people Love about their VCS - Part 1 of 4”), and also this section in an article I wrote )