6 ms·

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

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.

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.