5 ms·

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"

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

hsmyers 16y ago
It is almost as if there is a law of geek nature that says 'For every evangelist there must be a troll...' It is hard to appreciate the useful content when combined with gratuitous attacks.
yawgmoth 16y ago
It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating between tools is a lot of work. 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.
- selectnull 16y ago
  Exactly! 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...
  - pilif 16y ago
    Whenever I'm touching one of my old projects (some even in CVS), I'm migrating them to the system I'm using at the time. 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.
    - selectnull 16y ago
      That's certainly one good way to go. The other is to leave them where they are. Whatever works is the good way.
- jarin 16y ago
  In my experience, going from SVN to Git has been as simple as doing git-svn clone and then pushing up to Github (or Assembla). Then again, I agree that there's a lot for the users to learn, so it's probably best done during a refactoring phase and you need at least one Git master to be available to answer any questions.
  - pilif 16y ago
    The migration on a technical level is easy. 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.
loup-vaillant 16y ago
> 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 "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. [1]: http://wiki.lesswrong.com/wiki/Fallacy_of_gray http://wiki.lesswrong.com/wiki/Fallacy_of_gray [2]:http://wiki.lesswrong.com/wiki/Oops http://wiki.lesswrong.com/wiki/Oops
- selectnull 16y ago
  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.
  - loup-vaillant 16y ago
    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.
    - selectnull 16y ago
      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.

hsmyers 16y ago

It is almost as if there is a law of geek nature that says 'For every evangelist there must be a troll...' It is hard to appreciate the useful content when combined with gratuitous attacks.

yawgmoth 16y ago

It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating between tools is a lot of work. 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.

selectnull 16y ago
Exactly! 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...
- pilif 16y ago
  Whenever I'm touching one of my old projects (some even in CVS), I'm migrating them to the system I'm using at the time. 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.
  - selectnull 16y ago
    That's certainly one good way to go. The other is to leave them where they are. Whatever works is the good way.
jarin 16y ago
In my experience, going from SVN to Git has been as simple as doing git-svn clone and then pushing up to Github (or Assembla). Then again, I agree that there's a lot for the users to learn, so it's probably best done during a refactoring phase and you need at least one Git master to be available to answer any questions.
- pilif 16y ago
  The migration on a technical level is easy. 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.

loup-vaillant 16y ago

> 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 "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. [1]: http://wiki.lesswrong.com/wiki/Fallacy_of_gray http://wiki.lesswrong.com/wiki/Fallacy_of_gray [2]:http://wiki.lesswrong.com/wiki/Oops http://wiki.lesswrong.com/wiki/Oops

selectnull 16y ago
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.
- loup-vaillant 16y ago
  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.
  - selectnull 16y ago
    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.