This review (at least it's admittedly unscientific) suffers from a common problem of many critiques of software development practices: a lack of appreciation for diversity. Software development spans a much wider range of conditions than almost any other human activity, scaling from a lone developer working part-time on a personal project up to teams of thousands of devs and testers working on billion dollar or perhaps even life-critical software.
Software development efforts can span 6 or more orders of magnitude difference, and can differ in character enormously (such as between a scheduled release cycle of unpatchable, life-critical software vs. a constantly updated web site). Yet despite this huge diversity, most commentators insist on ignoring it and giving blanket advice as if it were equally applicable to every development effort in the history of the Universe.
The various drawbacks and benefits of different source control tools will matter differently to teams of different scales and processes. For some teams SVN may make sense, for some it may not be even remotely feasible. I've heard of teams that could not use git because of scaling issues (shocking as that may sound).
It's hard to take advice seriously that doesn't acknowledge these issues. It's no different than someone talking about web infrastructure and saying that the best solution is php/apache and mysql running on two separate servers. That may be a fine solution, but it's overkill for some scenarios and unsuitable for a lot of other scenarios. Sometimes you need a thousand servers, sometimes you only need a single 128mb ram VPS, sometimes you need scala or erlang, sometimes you don't need anything more than static html, sometimes you need a REST backend, sometimes you don't, sometimes you need nosql, sometimes you don't. What works for amazon.com may not be applicable to a personal vanity page or to twitter or google or paypal.
Software development efforts can span 6 or more orders of magnitude difference, and can differ in character enormously (such as between a scheduled release cycle of unpatchable, life-critical software vs. a constantly updated web site). Yet despite this huge diversity, most commentators insist on ignoring it and giving blanket advice as if it were equally applicable to every development effort in the history of the Universe.
The various drawbacks and benefits of different source control tools will matter differently to teams of different scales and processes. For some teams SVN may make sense, for some it may not be even remotely feasible. I've heard of teams that could not use git because of scaling issues (shocking as that may sound).
It's hard to take advice seriously that doesn't acknowledge these issues. It's no different than someone talking about web infrastructure and saying that the best solution is php/apache and mysql running on two separate servers. That may be a fine solution, but it's overkill for some scenarios and unsuitable for a lot of other scenarios. Sometimes you need a thousand servers, sometimes you only need a single 128mb ram VPS, sometimes you need scala or erlang, sometimes you don't need anything more than static html, sometimes you need a REST backend, sometimes you don't, sometimes you need nosql, sometimes you don't. What works for amazon.com may not be applicable to a personal vanity page or to twitter or google or paypal.