I've been proposing that we move from svn to git at work because I think it would be a really good fit for our current process. We are using svn along with a tool called savana which does user branches in svn. It's not a terrible solution when it works, but savana feels like a hack and we spend quite a bit of time managing branches and cleaning up after savana failures.
Git would solve a lot of problems, but it's also not without risk. Transitioning takes time, existing processes would need to be reworked, and people would need to learn the new tools. There's no doubt that git would be better in the long run, but it's hard to justify a transition today.
As a lower risk step towards git, I've been using the git svn functionality. With git, I can check out our master svn repository into a local git repository on my machine. Git is aware of all of our branches and tags. I can create a local branch from any remote svn branch and push any changes I commit locally back into svn at the right point.
A local git branch can completely replace the need for savana user branches, however the issue of sharing does come up. It's not uncommon for two developers to collaborate an a shared user branch related to a new feature. With user branches on the local machine, collaboration becomes a little more difficult. It's possibly for those users to collaborate on a shared user branch in svn, but then git is really not helping out much. Git does have many options for developer collaboration, but I don't think sending patch files around is really the kind of developer process that would work well for us. Perhaps using "git daemon" would work for us. It's really hard to say.
The bigger advantage of introducing git svn as replacement for savana is that the other developers can experiment with git on their terms and hopefully become familiar enough with git that later on switching out svn for git as the central repository would hardly even be noticed.