quite a few reasons, none of which aren't covered in tha parent post except for one, which is that subversion on test environments is a real pain to get working on various environments. As the dev team uses tortoise and always gets "there is a new version available, please update here" I have seen the unenviable position of having repos on staging environments rendered un-updatable except by tarball because subversion on the remote end refusees to work with the newly incompatible repository post a single commit from tortoise SVN 1.6.3 for example.
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?
I'm just saying in your case it seems as if people are busy enough as is. Switching VCS will disrupt workflow as they learn. My experience is that branches, while a pain in non-git systems are still used in the places you really want them to be used (release management), and most of the other features are mostly in the "nice to have" category. At that point it seems a better idea to simply use git-svn so you have the power of git without having to force a change in infrastructure.
(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.)
What I'm actually thinking of doing is using git for my own projects internally and as other devs help me out on those projects I'll induct them properly into how things work on that project, one small aspect of which will be git, and it won't be the only one, so they'll already be in a learning frame of reference from there. That said, keeping it as close as possible to the way it was is a good goal from a "I get this, it's easy to work with" perspective so I'd still really like to know if tortoisegit is as practical for real work as it appears to be from messing with it briefly in a VM.
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.
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?