I still use svn. For personal project, I have moved to hg. I use git occasionally. They all have its merits, and svn certainly didn't deserve "you should probably stop using it".
That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine".
It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oops"² in exchange for new powers. We sometimes even actively try to deny others the very powers we refused to take.
Here, you were very close to make that mistake about svn vs Git/Hg/Darcs. Git doesn't dominates svn yet, but I'm sure it will. Then, subversion will deserve "you should stop using it".
But most often, this mistake is made with programming languages (it's a variation on the blub paradox). And the effects are far worse there.
I said in my comment I agree with the post in that git is "better" than svn. But svn is not that bad that it deserves a jihad of git users that can not stand not having world domination of their fav tool. That is ridiculous.
Like I also said, I didn't like the tone of the article which was "svn is dead and you should be moving along".
I also think the article has a point. I just don't think it was written in most productive (dare I say fair?) way.
> We sometimes even actively try to deny others the very powers we refused to take.
Huh? Who was that directed at?
Imagine you're on a small team developing closed source software. Like many people, you already have SVN, your team already knows SVN, it's already integrated into build system and you're using Trac for ticketing. Based just on that, I would absolutely keep using SVN instead of transitioning to Git. Perhaps you disagree, but I hope you'll at least concede that's a reasonable position.
So, a better example in the svn vs git matchup would be the handling of locks for binary files. Assuming of course you can't fix it yourself.
You come from the "ya, well..." camp it would seem? Supremely confident that your choices are the correct way to do things, but when someone points out a valid difference, your answer begins with "Ya, well...". I see this all the time from brash young superstars.
I didn't say that. I actually agree with that.
My other point was more general.
Are people who say that "every tool has qualities, therefore they're all fine" always trying to say that it does not matter what tool you use? If they are worth their salt, they will choose tool A if tool A works and is "better" than B, but will not assume B is inheritable inferior in all projects. The whole idea is to recognize the qualities of tools and asking yourself if you can really use them.
Suggesting that one tool is always better enables a mindset similar to that in manifest destiny ("[God told us] our culture is better than yours, so be like us").
I'm not saying you can not be "gray" and "wrong", but being gray is not unconditionally wrong and certainly does not deserve to be called "poison".
Now it doesn't mean we shouldn't be weary of sentences like "right tool for the job", "every tools has qualities". While they are correct generalities, they are often used to justify not to change habits: "We'll use C++. Don't say that, every tools have qualities. Besides, this is a big project. Languages are just tools, and you better use one that fits the job".
You could try to go against this trend: "But, because it's big doesn't mean we have to use C++. It doesn't mean you have to use only one language. It doesn't mean you have to squeeze every cycle out of your CPU. What about C + Lua? Simplicity by default, and speed where you need it".
But if you have to overcome fear of changing one's habits, this won't be enough.
Also, you seem to think that no tool dominates another. With that I disagree. Let's start with a contrived example: Lisp vs Blub, where Blub is Lisp without macros. I think it's reasonable to say that Lisp dominates Blub. A similar reasoning led me to think that ML dominates Java and C#[1] (at least if I pretend libraries don't exist and programmers know ML).
Sure, it hurts feelings to say to someone that his favourite tool is strictly worse than some other tool. But it doesn't make it wrong.
Reconfiguring build servers, rewriting documentation/wiki pages which have SVN Uris (or anything at all regarding existing source control) in them for projects that have existed 5-10 years as well as having an entire team learn a new source control tool is no task to be taken lightly.
I have 15 GB of svn repositories. I don't plan to migrate them. I use mercurial for new projects and I'm fine with old stuff to live in svn.
Just like I use more than one programming language, I use more than one OS, I use more than one database backend...
Currently that's git.
So now I'm looking back on 52 repositories. 16 in CVS, 14 in subversion and 22 in git (all of them counted only once) created over the last 10 years.
I did spend multiple hours though fixing non-fast-forwarded merges, accidentally created merges after pulling, incorrect author names and one accidental force-push.
All of these I could have prevented using policy on the server, but I would still have had to help explaining the underlying issues in order to a) get the broken commit in and b) make sure it doesn't happen again. Explaining takes much longer than just fixing.
The problem isn't technical. It's human.
The more employees/team members you have, the more complicated it will become to put all on the same boat. My experience above comes from a team with 4 people of which two were already git users (one of them was me).
I don't want to think what this migration would have meant if we were 10 or even 100 people.