Firstly, most developers I have encountered in big corporations (and India) don't even give version control a thought - I thought it was programming 101, but I was shocked about the resistance I got when trying to persuade the team to use anything.

Second, the people I was trying to get to use version control could barely grasp the basics - branching, merging, frequent checkin's, updating your working copy - alien concepts - and that was using Subversion. I cannot even imagine trying to convince them to use a distributed model!

So my point is - distributed version control is probably great (I have never used it, but I have read a bit) for the clued in 20%, who work with others from the 20%, but if your team involves people mostly in the 80% don't even think about it - Subversion will have a market there for a long time to come ...

You're assuming distributed version control is harder to understand than centralised version control. That certainly hasn't been my experience.

Using svn or cvs, I find myself rummaging round in the docs to do even quite basic things ('recursively add everything in this directory', 'maintain a personal branch of an open-source project, and keep it in sync with new releases'). I've found bazaar and mercurial much more intuitive.

Maybe my experience is atypical. Maybe it's because of the particular qualities of the programs I've used, rather than centralised vs. distributed. But it's not obvious that distributed is harder.

That said, if people don't get version control at all (yip, there are plenty of them) then its probably going to be harder to convince them of the merits of both version control and a distributed model at the same time.

I have certainly learned in the last few month that changing the direction of a large team is no easy task, and convincing people to use any tool that is even slightly off the beaten track is going to make that task even harder.

Its sad - I wish there were more curious, keen to learn people when I work!

You do have to accept some constraints in order to use it successfully -- basically, git-svn doesn't seem to understand merging back-and-forth between different branches very well, so it encourages a much more linear, one-branch workflow than git does -- but it is still a huge improvement over stock svn, and it lets you inch your way into git, and gives you a platform from which you can lure your fellow employees into git one at a time.

Many (all?) distributed systems solve this issue by keeping repository metadata in one place at the root of the project rather than spreading it around in lots of .svn folders.

Companies just can't let go of legacy systems. That's why we still have companies running Cobol systems on OpenVMS. The term 'legacy' sometimes means permanent.

I've seen my co-workers, boss, and the consultants we've hired check in output files as well as source files and make commits with no comments. Forget branching, merging, and tagging. Unfortunately, in IT departments, you cannot assume people know anything about source control, even in 2008.

All I can say is thank god I don't have to touch their CVS modules, and thank god they don't touch mine!

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

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.

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.

Why should I care what color the bike shed is? The really, really short answer is that you should not.

http://www.unixguide.net/freebsd/faq/16.19.shtml

For the record, I am not sure if I could build a safe bike shed over a weekend.

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.

  Subversion, despite its marketing hype, has no support for branching and merging

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!)