Earlier quoted context omitted.
Even used like that, there are clear advantages to using git to preform that model rather than SVN. To really get the proper "just like SVN" experience you would have to find a way to make git suck at branches and merging, at the least.
I never found actually doing branches and merges in SVN any more difficult than git, not sure what the big differences are? OTOH not having to do the merges on the shared repo is much better and avoids the "don't checkout HEAD just yet 'cos it's all manor of fucked up right now" problem.
It is obviously a hard thing to quantify, but relative pain of branching and merging is apparent through the different version control styles commonly advocated/actually seen for both systems. As a simple example, while this (http://nvie.com/posts/a-successful-git-branching-model/) is certainly possible in SVN, I have never actually seen an SVN shop consistently doing that. To the extent that any I have seen do follow that model, they do so essentially at gunpoint, not because it is a pleasant thing to do. On the other hand that sort of thing is exceedingly simple and pleasant in git. As a consequence, in the real world, people are much more willing to employ both with git without any hesitation at all.
Also poorly quantifiable is the sense of fear or anticipation that courses through your veins when you hear the phrase, in an SVN shop, "Hey, I've got a feature branch I want to merge in."