I'm not sure how he can honestly call Subversion a "best of breed" centralized VCS while it still doesn't support merge tracking in a stable release.
And is it just me, or are the use cases for SVN proposed in the developer's mail he links to fairly limited? Making SVN "the best tool for organizations whose users need to
interact with repositories in complex ways" is fine and useful, but they're essentially conceding that the DVCS approach is a better fit for most open source projects.
DVCS is pretty much the best approach for anything. Centralized version control systems might be OK, but SVN is not OK. The whole "everything is a directory" model was a huge failure. Replacing CVS by eliminating the one thing that it got right -- first class tags and branches... yeah, great idea, guys.
Anyway, SVN's time has come and gone, and if I were the author I would deprecate it and never look back. It was excellent while it lasted; it didn't lose data, it was somewhat fast, and it got people into version control. But now it's an ancient relic; its existence serves as a great example of how not to implement a version control system.
Sorry if I sound harsh, but ... it's time to let go :)
I don't see why people get so excited about version control, myself. There are so many other areas of tech where it's more productive to follow the latest & greatest, or learn about new techniques. Sure, istributed is an improvement, but for many people, even CVS would be "good enough".
BTW, you do sound a bit harsh, and I hope they continue to maintain SVN for many years to come. It's sort of a thankless job compared to working on something new and flashy, but I'm glad people put that kind of dedication into their open source work, instead of just chasing after the latest fad.
I think DVCS is probably easier and less sexy/revolutionary then people make out.
But I agree - whilst important, its hardly that exciting - unless your current VCS is causing a problem. At best a DVCS can remove barriers to productivity.
I think this is an example of people fussing over things they can understand and control, to avoid facing up to the harder problems they have on a day to day basis.
Like that story of the design of a new nuclear reactor - everyone was afraid to commit to things, to comment and collaborate on things that were hard, but when the subject of a handrail around the reactor was brought up, suddenly there was a deluge of opinion on it - it was something people could understand and feel like they were contributing.
Often the debates over the less significant problems are the most heated.
> I don't see why people get so excited about version control, myself.
Well, for most programmers it's one of their most frequently used applications. Subversion is annoying because operations are really really slow. "svn ci" takes forever as it slowly calculates changes, sends them to a remote server, waits for svn to slowly update its database, and finally wait to get a response back. I want to commit my changes, not take a 15 minute nap. Git creates a few files, and it's done. Commits are instantaneous.
Subversion also has other annoyances. If you want to save your changes before updating, that's too bad. "svn update" can destructively modify your working copy (with no way to revert), and there's no way to commit when Subversion decides that your working copy is out of date. You have to merge upstream right then and there, so fuck you. This means that you have to make a copy of your working copy with "cp" just so you don't lose data. Then you have to manually merge. What!? This makes me pine for the days of "foo.c", "foo.c.BAK", "foo.c.BAK.OLD", etc. ;)
Git handles this the right way. You can commit your changes whenever you want. They're saved forever, and you can always get back to this state. If you feel like pulling in upstream, you can. You then have the opportunity to merge, or say "fuck the merge" and forget it. Git doesn't care when or if you merge upstream into your working copy. You're never forced to do anything; you decide how to work, the computer doesn't tell you what to do. (You can even do it non-linearly; make a branch "foo", do the upstream merge in "master", pull a few upstream changes from "master" into "foo", work on that for a while, pull the rest of the changes in, and finally merge foo into master and send master back to the server. Git handles all of this perfectly, so instead of worrying about what the version control system wants to do, YOU get to decide what to do.)
Finally, Subversion, despite its marketing hype, has no support for branching and merging. Yeah, it has "cheap copies" that you can use diff3 against. What a joke. (SVK is better.)
Anyway, please don't think I'm some rails weenie that just switched to Git last week because some blog told me it's cool. I've been using it for over two years, not because it's cool but because it instantly made programming more enjoyable.
Like I said, I don't want to be too mean to Subversion, since that's never the way to advocate something ... but switching from Subversion to Git feels like ending an abusive relationship. You don't realize how bad it was until it's over.
I think "svn ci" sometimes being a little slow is a total non-issue, at least in my experience. Admittedly, the project I use SVN for is only ~750KLOC, but I think that probably includes the vast majority of people using VCSs for source code.
Subversion, despite its marketing hype, has no support for branching and merging
That is overstating the case (SVN supports branching just fine), but I think that is SVN's only real problem is how terrible merging is (that and the whole centralized model in general, but there are plenty of circumstances in which a centralized VCS is perfectly acceptable). Hopefully merge tracking in 1.5 will improve things.
I think "svn ci" sometimes being a little slow is a total non-issue, at least in my experience.
Well, if you haven't used git, you don't know what you're missing. "svn ci" seems fast. But try git and you will be amazed.
SVN supports branching just fine
No, it supports cheap copies. It has no idea what a branch is. As far as svn is concerned it's a directory. (You can even "svn copy" a single file. People do this, and it makes the nightmare called merging even more of a nightmare. Araaggghhh!)
Actually, stuff like git changes how a developer does development. It encourages quick experimentation which can considerably affect the result. I don't care whether it's the "D" of "DVCS" enables it or not, but the end result seems significant.
And is it just me, or are the use cases for SVN proposed in the developer's mail he links to fairly limited? Making SVN "the best tool for organizations whose users need to interact with repositories in complex ways" is fine and useful, but they're essentially conceding that the DVCS approach is a better fit for most open source projects.
http://svn.haxx.se/dev/archive-2008-04/1020.shtml