First, as I said, my use case is highly non-standard. I'm the only developer on my project, so I don't have to worry about collaborators. I do my work on a lot of different computers, so it turns out that (for me) one of the biggest advantages provided by version control is effectively synchronizing source code between systems, many of which get erased (e.g. new OS installed ) on a regular basis, all of which have internet access. It is important that I be able to quickly and simply set up a development environment on a new system -- a somewhat unusual requirement, I realize. Under these circumstances the primary advantage -- not just of git, but any DVCS -- becomes a major disadvantage. The whole point of DVCS is that the ability to commit is separated from the ability to update the central repository (git push), where they are the same in centralized VCS. However... I ALWAYS want to push when I commit. If I commit to a local repository on a machine that gets wiped, it does me no good. It needs to get updated in the central, online repository every time. This can be done with a short simple shell script, of course, but remember: I need it it to be as simple as possible to set up a new development environment. This adds an extra step, and if I neglect it, I can lose a lot of work. If I use SVN, I simply don't have to worry about it. It's automatic.

Another feature of SVN that I like, that's impossible with DVCS: revision numbers. With SVN, revision numbers increase sequentially from 1 to whatever number commit the last one was. DVCS can't do revision numbers because you can't determine the sequence of commits until after the commits are made (everyone has their own repository!). Being able to refer to r378 is a LOT nicer than referring to an arbitrary hexadecimal identifier. Having commit identifiers that convey information is a huge plus.

For me, these reasons are enough to outweigh the advantages of having access to repository history while offline and the better handling of branching that git offers.

(If checking out one more thing results in pain, you should think about automating the checkout too... This line of thinking has resulted in me keeping everything in git and using a single `mr` command (google will find it) to check out all my respositories when I'm setting up a new account.)

Revision numbers are not impossible with DVCS; bzr has repo-local revision numbers. But once a number becomes longer than 3 digits, I cut and paste it anyway; if I'm already pasting, the longer size of git's sha1s doesn't matter.

During my average day, I probably spend a few minutes total messing with svn. For my usecase, it's already optimum. The only way I could reduce that time is to not put in any commit messages :/

Anecdotally, this is fairly common. I have known people that did not realize they had fairly bad back pain until they went to the doctor for something else and had it treated.

Sometimes, it is only in absence of something that we really notice it, especially if it is truly chronic. I suspect most people have gone somewhere with a fairly loud background noise. At first they may notice it, but after being there for a while they may forget about it and may even forget it was ever there. But they will notice and realize how annoying it was if that noise ever stops.

I type 'svn commit' 'svn update', it works. quickly.

For me, it's like suggesting I change from using 'cd' to change directory, to using 'awesome-cd' to change directory :/

What I can say is that I didn't realize how painful Java was for me until I started learning Python. That may be a closer analogy, though still not perfect.

Sometimes when I'm developing, and ready to commit something I notice I've made a few unrelated changes/bugfixes. I could just commit the whole thing at once, but that makes merging a hassle because I probably want to merge those bugfixes to trunk much sooner than any code which implements a new feature. So, I would need some way to commit only certain diff chunks from each file.

I understand from "http://www.gitcasts.com/posts/interactive-adding that git can do that. So far it hasn't been incentive enough to switch, but it's one example of the pain of subversion.

Until I switched to git. Only then did I realize how much pain I was suffering by avoiding branches. Now I use branching all the time.

I guess it's because I had nothing to compare to. I didn't know that branches can be done well.

See what happened with _why? He nuked everything, but none of it really went away. With CVCS, the community would have lost everything.

That may be, but they're the only community I see being extremely in-your-face about their tool and how it's clearly beating the pants off everything else. Personally, I'd be more interested why they feel the need to declare its goodness so loudly, when if it really is as awesome as these articles make it sound then it'll spread like wildfire by word of mouth.

emacs changed the way I write code, and made me wildly efficient compared to before I used it. That doesn't mean I'm going to go and start browbeating people into using it. The git community seems to be blind to the notion that git (as wonderful as it is) might not be for everyone.