Still Not Switching To Distributed Version Control

If Joel Spolsky says it, I (almost always) believe it. He's a brilliant programmer and a terrific writer. But just because he tells me I should love Distributed Version Control doesn't mean I can. In his most recent article he says:

For those of you that have been living under a rock, the single biggest change in developers’ lives in the last decade (besides Stack Overflow, natch) is Distributed Version Control. DVCS is such an important improvement over the previous generation of centralized version control (Subversion, CVS, etc.) that it’s a required upgrade, even though it’s honestly a bit harder to use.

Digging deeper, back in 2010, he said:

With distributed version control, the distributed part is actually not the most interesting part.

The interesting part is that these systems think in terms of changes, not in terms of versions.

That’s a very zen-like thing to say, I know. Traditional version control thinks: OK, I have version 1. And now I have version 2. And now I have version 3.

And distributed version control thinks, I had nothing. And then I got these changes. And then I got these other changes.
...
When you manage changes instead of managing versions, merging works better, and therefore, you can branch any time your organizational goals require it, because merging back will be a piece of cake.
...
This is too important to miss out on. This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.

Or, to put it another way, I’d go back to C++ before I gave up on Mercurial.

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

Seriously, how can I keep using Subversion after reading the above? The only catch is, I've experimented with git I'm completely underwhelmed. Yes, it technically works, but:

1. I have to give up the Unix style notion of managing files in version control. Using Subversion I can cat, mv and cp files just like I would from the command line.
2. I have to give up notion of partial checkouts. When someone has committed 3 gigs of videos to a directory, it sure is nice not to have to check them out.
3. I have to give up the simple everything's a file model, where tags and branches are managed by creating copies of files and directories.
4. I have to give up my incremental version numbers. I love the simplicity of being able to attach a version number to a software release, and being able to roll back to that anytime to see what's what
5. I've yet to run into a nightmare merging scenario alluded to above. Before I start work on any customer's project I create and often use a bugfix branch. And before I deploy, I merge that bugfix branch back in. It's a system that's been working well for years, and wouldn't develop without it.

I'm not saying that git and other DVCS aren't fantastic for some applications. I'm usually operating in lone-wolf mode, with only a few other folks accessing a repository. With a larger team, or better yet, multiple teams, DVCS's benefits may be a no-brainer.

Using git reminded me of the early days of Enterprise JavaBeans. The technology was so cool, and so fancy. Just the word "Enterprise" made it sound like you had hit the big time. So we opted for the whole kit and caboodle: session beans, entity beans, Weblogic container, multiple servers; the whole deal. What we found out, very much the hard way, was that the system was terribly slow and terribly bloated. The only true benefit of our solution was that we were buzzword compliant. PHP + MySQL would have run circles around that ridiculous setup. We had successfully solved all sorts of problems we didn't have (ones that a large enterprise might have, perhaps?), and neglected the ones that really mattered (delivering pages quickly and querying a small database efficiently).

I suppose it all boils down to: use the right tool for the right job.