Well, when you revel in your own ignorance of the technology you are trying to use then it's no surprise you run in to friction. 5 minutes on google could have cleared up most of his gap in understanding how SVN works.
Googling your questions and figuring it out does not an interesting article make. I find this a fine counterpoint to people who come to git from other version control systems and baulk when they see it, it's an interesting alternative perspective to the whole "good UI/bad UI" discussion.
This has little to do with git vs SVN and everything to do with an inflexible and inexperienced know-it-all being incapable of even trying to pick up an older technology. Read through his replies to the comments, it's sad to see really.
You could have replaced the topics of svn and git with C++ vs python or stored procedures vs parameterized queries and it would have been practically identical apart from people would have told him to sod off and grow up instead of changing their process.
That's actually the only positive take away from this article, it is actually really easy to change version control system if you want to.
I must admit I'd love to see the post he'd make after being forced to use MS VSS :)
"This has little to do with git vs SVN and everything to do with an inflexible and inexperienced know-it-all being incapable of even trying to pick up an older technology."
s/older/unfamiliar/
I absolutely agree with that substitution. You can (and I certainly do) see the exact sort of thing going on in the reverse direction with various technologies. I'm guilty of it myself. That's why I find it interesting.
What's better, a development team full of developers who are flexible enough to use a crappy technology, or inflexible enough to move the product to a superior technology? It depends on moving costs and the difference between technologies, but in some cases I think that inflexibility is better.
