Live data from Hacker News

It’s time to stop using Subversion

altdevblogaday.org

101–110 of 112 posts

Re: It’s time to stop using Subversion

#101
post #100
post #99

Earlier quoted context omitted.

I read your links. I also use subversion merging every day while maintaing feature and maintenance branches. It works fine and involves significantly less complexity than git.

I use git everyday. I don't know what this complexity is you speak of. It took me a weekend to learn git, and about the same for subversion, but git gives me more flexibility and power.

Flexibility and power come with complexity, and in his case, provide no practical benefits to most organizations. I use git regularly when interacting with open source projects, but don't see the value in it's added complexity and decentralization in corporate environments.

Re: It’s time to stop using Subversion

#102

Earlier quoted context omitted.

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.

Re: It’s time to stop using Subversion

#103
post #91

Earlier quoted context omitted.

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 conced…

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.

Re: It’s time to stop using Subversion

#104
post #81
post #65

Earlier quoted context omitted.

I would downvote this post if I had the power. It's wrong to the point to either be lying or trolling.

Since you can't downvote, you could try explaining your position.

I did: the post is nonsensical. Can't get into tight spots with SVN? It's hard to imagine anyone that's actually used SVN saying that.

Re: It’s time to stop using Subversion

#105
post #81

Earlier quoted context omitted.

Since you can't downvote, you could try explaining your position.

I did: the post is nonsensical. Can't get into tight spots with SVN? It's hard to imagine anyone that's actually used SVN saying that.

Subversion is simple enough that while you can find ways to mess up your local working copy, it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess. Git is a complex, fragile (in the wrong hands) VCS.

Re: It’s time to stop using Subversion

#106

Earlier quoted context omitted.

And yet some of us are stuck using CVS.

Some of us are stuck using Clear Case or Visual Source Safe. Whatever source control you're using, someone always has it worse.

"someone always has it worse"...

That was my previous place of employment: in-house perl scripts wrapped around RCS. Absolute nightmare.

Re: It’s time to stop using Subversion

#107
post #105

Earlier quoted context omitted.

I did: the post is nonsensical. Can't get into tight spots with SVN? It's hard to imagine anyone that's actually used SVN saying that.

Subversion is simple enough that while you can find ways to mess up your local working copy, it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess. Git is a complex, fragile (in the wrong hands) VCS.

> it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess

More falsehoods. While it may be true that it's harder to corrupt the central repo (as opposed to your copy of it) [1], it's hard to lose work in Git even locally. Git is not fragile, nor complex. It has more features than SVN since it has more capabilities but most of the stuff just works.

It sounds to me like you don't really know much about Git. If you think you lost a change, you probably didn't. Unless a GC has happened the change is still in the repo, you just don't have any pointers to it. You just need to query the db for it (or if you know the hash code you can use that) and make a branch or tag to the revision when you find it.

Ironically, I find Git much more stable than SVN because in Git change sets are first class and cryptographically signed. I can always find the exact one I was previously working with if need be. Changes not being first class in SVN means you can't tell if you're looking the original change, the result of a merge, etc.

[1] It can be done pretty simply with branching though. If you share branches with each other it is possible to set up a situation where all further checkins for most users will create a large amount (depending on the previous branches) of fake conflicts.

[1]

Re: It’s time to stop using Subversion

#108
post #91

Earlier quoted context omitted.

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 conced…

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

Re: It’s time to stop using Subversion

#109

I'm kinda annoyed that every once in a while, somebody has to come along dissing svn, prophesying its inevitable demise and glorifying git. Yes, git is "better" than svn, I agree. I like the message in general, but I don't like the tone of it. 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…

> They all have [their] merits 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 "oo…

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

Re: It’s time to stop using Subversion

#110
post #91

Earlier quoted context omitted.

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 conced…

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.

Post reply on HN