Subversion has no way to commit local patches so that you can test out your changes, split up commits functionally, generate patches easily so you can send them to a review list, or any of these great features. Git does not have this problem; in fact it has a very nice set of tools for working this way. I won't go into the details of that, as most readers probably know it already, other than saying that it's amazingly simple and easy.
The pain comes when you're an outside contributor for a Subversion project: you might be testing some experimental changes that you don't want to commit to the public repository. Okay, you can edit the files and svn diff locally but this pathetic compared to the power of git commit and git format-patch
- You're stuck doing one functional change, and only one functional change. Because you have no way to create a patch series. It's either everything in one commit, or nothing at all.
- Even when you have commit access, often this results in multiple functional changes being squashed into a single commit. This is very bad.
- Subversion provides no way to add commit messages or authorship to the diff generated by svn diff, so contributors are left out in the cold.
- Yes, if you have commit access you can provide this meta-data, but you're still pushing directly to the repository with no review what-so-ever.
Thankfully Sourceforge does at least provide rsync access to the Subversion and CVS repositories so git svn clone can be both fast and bandwidth efficient. Unfortunately, however, it seems that Subversion chokes on anything but patches generated by Subversion itself (including standard GNU diff format.)
Everyone should be using Git (or at least some distributed version control system with similar features.)