Hacker News Reader

You use words and phrases such as "poisonous meme", "should be fought tooth and nail", "demonstrably better in every way for every foreseeable usage", "dominates"... Strong words.

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.

Some of my words ("poisonous") strengthen my statements. Others ("demonstrably better") restrict them. I'm aware that the relative power of tools isn't a total order. For instance, I disagree with "git > svn". For now. Therefore, bashing svn and praising git specifically isn't a good idea. But distribution may well dominate centralization for version control in general. I think the article has a point there.

Like I said, in general, I agree with the message (of the article) which is in a nutshell: git is newer and uses a different paradigm than svn which helps in many ways.

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.

But SVN really is fine. And Git definitely isn't better than SVN in "every way for every foreseeable usage."

> We sometimes even actively try to deny others the very powers we refused to take.

Huh? Who was that directed at?

I'd love to read a post where someone decided SVN is superior for their purpose, and their stance is defensible. I can't think of any reasonable use cases.

I'm not personally a big SVN defender/apologist, but I'll bite.

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.

Of course transitions always cost something. For instance, C++ is the best when all your developers know C++ and have to extend a C++ code base. This examples are short term, and don't answer the question "is the new tool eventually better than the old one"? If so, consider switching costs. If not, don't even bother.

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.

well obviously, but the point is in a vaccuum, git as a tool appears to be superior in every way that matters.

Most people neither live nor work in a vacuum.

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.

ya, well, factors external to the merits of the two tools is irrelevant to the question I intended to pose. My question could have been worded better, sorry for the confusion. loup-vaillant's explanation is clearer. ;)

> Git definitely isn't better than SVN in "every way for every foreseeable usage."

I didn't say that. I actually agree with that.

My other point was more general.

Who made you the authority of what is "better"? Decisions to use tools comes from context, and there is nothing wrong with choosing a tool that fits the job.

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".

First, I agree 100% with what you just wrote. To the letter, at least.

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.

[1]: http://www.loup-vaillant.fr/articles/classes-suck