4 ms·

I've observed the opposite in computing more frequently. Many people seem to care too much about appearances, when using a simpler or cheaper tool is better ove

I've observed the opposite in computing more frequently. Many people seem to care too much about appearances, when using a simpler or cheaper tool is better overall. My desktop computer is over 10 years old. This is hard to believe for many people. Why don't I upgrade? The reason is that a 10 year old computer is plenty capable for my work. I don't see much reason to upgrade now or in the near future. The hardware is still in good condition, and until it breaks in a way not easily repaired or my needs change, I will keep using the computer. Another example is software. I see this dynamic among many Git users. I use primarily SVN for version control in personal and work projects. These are projects with no collaborators. SVN has less friction in my opinion. Many Git users I know seem to think that because I use SVN regularly that means I am too stupid to use Git. I'm not, and at this point I'd offer to show people who think so my public GitHub profile as evidence now that I am contributing more frequently to an open source project. I think many of these Git users would find that SVN has less friction and is an overall better choice for certain small projects if they gave it a chance. But to many, using Git is partly about maintaining an appearance of being elite, and they don't want to look like a newbie by using SVN.

gurkendoktor 9y ago
> at this point I'd offer to show people who think so my public GitHub profile as evidence That evidence won't hold up because you can access GitHub repositories using Subversion :) https://help.github.com/articles/support-for-subversion-clients/ https://help.github.com/articles/support-for-subversion-clie...
barrkel 9y ago
I used cvs, svn and git, sequentially when they were most popular. Every step along the way was a big improvement, and the step from svn to git is a much bigger improvement than cvs to svn. Svn is a pile of crap. Remote operations take ages. Switching branches takes ages. Applying the same diff to multiple branches - you're better off extracting your own diff files and applying them manually. In fact creating branches is such a PITA you just don't bother. Stashing work in progress - again, create your own diff files. Svn was such a pile of crap I built my own system to extract and restore diffs of work in progress, as well as a tool using 3-way diffs for handling conflicts when base moved on after I needed to restore my diff.
- btrettel 9y ago
  Your use case differs greatly from mine, and this is what makes me prefer SVN most of the time. I tried to make this clear in my first post, but I'll explain in more detail. I agree that SVN doesn't do branches right. If I needed to use branches, I'd use Git or Mercurial. But the projects I use SVN for have no collaborators and only one version of the files. There is no need for branching here. So the branches argument is irrelevant. (And for what it's worth, I've heard this argument from a half dozen people who have tried to make me switch to Git.) "Stashing" is a Git term, and again, it doesn't really apply to my use cases because there's only one version of the files and I'm the only one using the repositories. I use version control so that I can keep track of the history, roll back changes if necessary, and keep my files synchronized across a few computers. There's no collaboration involved. This is where SVN is advantageous. I am not claiming that SVN is advantageous in all cases, just the ones my small projects fit in. And for me, that's most of the cases I use. As for remote operations, I haven't found that to be the case. And I haven't mentioned the SVN features I like that Git doesn't have either.

gurkendoktor 9y ago

> at this point I'd offer to show people who think so my public GitHub profile as evidence That evidence won't hold up because you can access GitHub repositories using Subversion :) https://help.github.com/articles/support-for-subversion-clients/ https://help.github.com/articles/support-for-subversion-clie...

barrkel 9y ago

I used cvs, svn and git, sequentially when they were most popular. Every step along the way was a big improvement, and the step from svn to git is a much bigger improvement than cvs to svn. Svn is a pile of crap. Remote operations take ages. Switching branches takes ages. Applying the same diff to multiple branches - you're better off extracting your own diff files and applying them manually. In fact creating branches is such a PITA you just don't bother. Stashing work in progress - again, create your own diff files. Svn was such a pile of crap I built my own system to extract and restore diffs of work in progress, as well as a tool using 3-way diffs for handling conflicts when base moved on after I needed to restore my diff.

btrettel 9y ago
Your use case differs greatly from mine, and this is what makes me prefer SVN most of the time. I tried to make this clear in my first post, but I'll explain in more detail. I agree that SVN doesn't do branches right. If I needed to use branches, I'd use Git or Mercurial. But the projects I use SVN for have no collaborators and only one version of the files. There is no need for branching here. So the branches argument is irrelevant. (And for what it's worth, I've heard this argument from a half dozen people who have tried to make me switch to Git.) "Stashing" is a Git term, and again, it doesn't really apply to my use cases because there's only one version of the files and I'm the only one using the repositories. I use version control so that I can keep track of the history, roll back changes if necessary, and keep my files synchronized across a few computers. There's no collaboration involved. This is where SVN is advantageous. I am not claiming that SVN is advantageous in all cases, just the ones my small projects fit in. And for me, that's most of the cases I use. As for remote operations, I haven't found that to be the case. And I haven't mentioned the SVN features I like that Git doesn't have either.