Any sort of branch/merge problems I encounter are mostly coders working on mutually incompatible versions of the base system. Not on a file level but rather on a protocol/format level
No mere source control system will be a hurdle of the same size as the hurdle of co-ordinating all the developers who broke each others preconditions.
---
So a switch to git will be best for projects with extremely stable interfaces where the branch/merge mechanism is the most time consuming part. Think: linux kernel, stable protocol services.
But where developers have to collaborate while modifying a shared framework git makes little difference. Think: early stage GUI frontends, or server components which inter-depend on message formats which are evolving.
Those same mechanisms break just as badly as svn when you need to coordinate 10+ developers. The communication overhead of the developers dwarfs the way they sync files.
This is not a problem with git, and the being able to push updates directly to the staging environment can also be non -trivially handy too.
That said, that's a minor annoyance vs the full blown excellent points that the original article makes about the advantages of git over subversion, so I'm a bit puzzled as to why this question is being asked, did you not think that the things covered in the article were worth anything?
(Incidentally, you can turn off subversion's auto-updating. I try to keep all my computers running the exact same version of subversion for largely the same reasons you mention.)
Someone care to save me from a couple of days in windows again? :)
Wrt git svn, last time I tried that it started version controlling the .svn directorise o_O. Which was fine for git svn but the tortoise svn users were completely screwed on a checkout.
Wrt subversion versioning woes, yeah, it's kinda a solution, but at the same time I'm not the system administrator and really don't want to be, and trying to enforce "don't update" would suck even if I were.