Meanwhile: To claim that SVN is intrinsically easier to understand than DVCS is to be very shortsighted. Subversion is a more mature technology: It's eight years old, and is conceptually based on CVS, which goes back to the eighties. DVCS is all of eleven years old in its eldest incarnation (according to Wikipedia) and the current generation of tools (git, Bazaar, Mercurial) date back only to 2005.
DVCS is a maturing technology. One of the things that happens as a technology matures is that people learn better ways to explain it to new users, build better interfaces, build better infrastructure.
If you don't think that DVCS makes enough sense to non-geeks yet... give it time.
The article isn't really about SVN vs all DCVSs, though, it's specifally about subversion's interface vs. git's.
There's no reason a DCVS can't have a clean, easily usable interface (darcs's is better than git's, for example), but the git developers have focused on features and raw power over usability.
distributed anything is usually hard for people to wrap their heads around the first time.
I don't think that's necessarily so. Have you ever tried to get an office full of people to collaboratively author a Word document? What's their instinctive behavior? They all grab copies. Then each of them hacks away on their copies. Sometimes two or three of them email their hacked copies to each other and mash them up, using cut and paste. Eventually some poor SOB has to get everyone to email over their individual versions so he can merge them. Hopefully they've all been using Track Changes (which is, in a sense, a poor man's facsimile of a single-document DVCS!); otherwise it's an even bigger clusterfuck.
That's a distributed model. Ever since the invention of photocopiers and email attachments, people have had to develop a very good understanding of how that model works, and how it fails.
It's tempting to think that the way to sort this out is to centralize it. But in my experience, centralized document-management systems are not that intuitive, which drives people to secretly work around them. ("Why can't I save my changed document on the shared drive? Oh, no, Joe checked it out and then went on eight-week vacation! I'll just stash my edited version on my local drive and distribute it via email." Or, "I created an alternate version of the doc, but I don't dare upload it to the shared drive because I might make another mistake and overwrite the official version. That always makes the admin really mad. So here it is on this USB stick.")
I think the most confusing aspects of version control are the navigation of history (just look at the wacky extreme that Apple' Time Machine designers went to in order to make it very obvious that you're looking backwards in history), and merging, particularly merge conflicts. But those aren't special features of DVCS; they're tricky no matter which VCS you use.
Meanwhile: To claim that SVN is intrinsically easier to understand than DVCS is to be very shortsighted. Subversion is a more mature technology: It's eight years old, and is conceptually based on CVS, which goes back to the eighties. DVCS is all of eleven years old in its eldest incarnation (according to Wikipedia) and the current generation of tools (git, Bazaar, Mercurial) date back only to 2005.
DVCS is a maturing technology. One of the things that happens as a technology matures is that people learn better ways to explain it to new users, build better interfaces, build better infrastructure.
If you don't think that DVCS makes enough sense to non-geeks yet... give it time.