Average Rating: 4.2/5.0Number of Ratings: 2184Number of Reviews: 13
My Review of Apache Subversion
|You have not rated or reviewed this project.Click below to rate/review.||My Rating:|
Subversion was chartered specifically to create a drop-in replacement for CVS -- something that worked similarly, but was friendly to the HTTP infrastructure and addressed some key limitations like the ability to version the directory tree structure. It's done what it set out to do, it's reached a stage of maturity and ubiquity, and I've found it to work reliably and well.
Of course most of the interesting work on source control is now being done elsewhere, in projects that intentionally aren't carrying any baggage from CVS and before.
I'm sure at some point in the not too distant future, my team will be moving to something like git, because that's indeed the next evolutionary step. Who wouldn't want smaller working copies, faster updates, and better, legacy-free approaches to merge drudgery, etc?
But more integrations and tool support are needed -- as well as working connectors for services like Ohloh, and project hosting at places like Google Code, Sourceforge, etc, before I can fully make the leap to a late-model revision control platform, instead of just dabbling. I'm doing my little bit to push that forward, working on a git integration with our content management platform and bugging my vendors for git support.
Anyway, Subversion has been a good friend at work for about 5 years, and will be for a while longer before we move on ... and I don't feel any need whatsoever to beat it up for not being designed from scratch in the 21st century. We'll move on someday, but we won't go away mad.
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 http://use.perl.org/~mugwumpjism/journal/30574, and also http://utsl.gen.nz/talks/git-svn/intro.html#sux )
This is a response to drbrain's review, because I think he's confused about a number of issues.
* Merge-tracking (a la p4 integrate) is coming in svn 1.5, and is already mostly working on the trunk code. You can test drive it today.
* 'svn diff' now natively supports -u, -b, -w, and other things.
* You *can* set the default diff arguments in your ~/.subversion/config file.
* "Feels" slower? Some commands are slower, some are much faster. It's all about amortizing total speed over various commands. Try timing 'svn diff' vs. 'cvs diff'. (Hint: one hits the network, one doesn't.)
* 'svn log -v -r123' tells you everything about one changeset.
* repo corruption? I don't buy it. working copy corruption has happened before though, so yes, that needs some work.
Yes this is what im talking about when I define 'userfriendly' and 'fast'. SVN seems to have so many more options than CVS, which makes CVS seem useless to me. SVN seems more like a replacement. A better one.
Subversion is imho one of the most overrated projects in the open-source community. It claims to be a substantial improvement to CVS but mostly fixes phantom problems.
Subversion never fixed a single problem that I have with CVS. Instead, it offers a branching approach that is completely unusable for my practical purposes.
Contrary to popular belief, a migration from CVS to SVN is not a must. Check your needs, test both systems, check other options like git, and then take your own decision.
I'm far from slating subversion, but its developers should drop the claim of subversion being the natural successor of CVS.
Just a quick note that WANdisco now have registration free SVN Bianries and Support:
While claiming to be an improvement over CVS, SVN has removed one of the most basic features of a revision control system: showing the history of a file across branches. Basically if you use SVN with more than one branch, you loose any meaningful history. How could anyone devise that bothers me to no end.
On top of that, the successive SVN versions are not always backward-compatible, even clients claiming to be of the same SVN version don't work with each other, SVN is also full of stupid bugs with file name lengths, it's a lot slower than CVS to show annotations or (what is left of) file history, and nasty and unreproducible bugs that leads to a checked-out version not matching the repository, and sometimes commits failing for no reason, etc.
Basically a failed and misguided attempt at a revision control system.
After having to suffer CVS at several jobs Subversion seemed like a wonderful thing. Being able to move files without worrying is great, and the concept of externals is brilliant. However branching is still a difficult thing to do and the use of directories as branches and tags seems unintuitive.
I've now switched all of my own projects over to git (which automatically imported my old Subversion history) and will never use Subversion again.
I would recommend mercurial over svn to those wanting cvs type commands as it provides a more modern perspective on version control.
SVN does happen to be what CVS should have been in many ways. The setup is easy and the commands are quite similar to CVS, in fact the same in many cases.
The best part I love on SVN is the folder structure management. If you want to change your file/folder hirerarchy in CVS then that is a big pain. Life is way smoother with SVN - you never realize (barring the prefix in the SVN comman) that you are not on your local filesystem - it is so simple and easy-to-manage. This speaks volumes of SVN and why one ought to use it over CVS - that is what I have started doing recently.