Reasons to switch from CVS to SVN

A number of colleagues have asked me about SVN and is it worth switching from CVS, the short answer is YES! So in no particular order, plus a few things that aren’t so great about SVN here’s my list of reasons to switch.

  1. One of the big questions I get is “can you import your CVS history”, the answer is it is possible, I’ve never tried to, but the reality is once you’ve migrated after about 6 months, you probably don’t need your history anyways (if you’re luicky), remember you always have the CVS repository to query. See this link for more info: http://cvs2svn.tigris.org/
  2. SVN has ssh support built in, so no more opening an ssh tunnel in a separate process, a big plus if your dev server is somewhere else
  3. SVN has nice commit hooks, post and pre which are much cleaner to use than CVS
  4. SVN is language agnostic, but has great support for python and many other languages from a tools perspective
  5. SVN has a very nice versioning scheme which is a little more sensible and it works, CVS’s scheme always seemed a little broken, especially when you started branching.
  6. You can remove directories and files very easily in SVN, try removing a directory in CVS without being an administrator of the cvs root.
  7. No more #cvs add -kb  for binary files (or forgetting the -kb) SVN has great handling for binary files
  8. There is ongoing active development of SVN with an emerging ecosystem of svn tools and integration with most if not all leading IDE’s (CVS development has stagnated IMO)
  9. The SVN server supports existing authentication and authorization infrastructure via the Apache based server, protocols supported: LDAP, Active Directory, NTLM, X.509, etc.
  10. SVN has good support for UTF-8
  11. SVN has a very powerful per file properties that can be added, like managing line endings, keywords, mime-type. You can also add your own arbitrary metadata.
  12. SVN has smart branches that don’t make explicit copies of files until you start changing things, great if you have large projects.
  13. All the basic CVS commands you are use to work in SVN, plus SVN has the svn status command which is the equivalent to and much easier to type than cvs -q -n update
  14. There’s a Tortoise client for SVN, for all you graphical types

A few things that aren’t easy enough to do…

  1. SVN uses a property option to do file ignores which is easy when applying a .cvsignore file from a converted project, but is generally awkward on a one by one basis, to use an existing .cvsignore file: # svn propset svn:ignore -F .cvsignore .  and to  add a  single file # svn propset svn:ignore "filename" . or you can edit the ignore properties with # svn propedit svn:ignore "dir_name"
  2. Setting up keywords like $Id:$ is harder than it should be and the feature should be on by default. You need to set the global setting per developer or do it file by file (yuch.) To set Id and Revision on an individual file: svn propset svn:keywords "Id Revision" your_file.ex

One Comment

  1. arnold says:

    Don’t know how large your teams are, but maybe its worth the effort to look at git ( http://git.or.cz/ ) I’ve been using SVN for years, though the hooks are quite handy, but in the end its as disappointing as CVS.  SVN is, from my point of view, the improvement of a poor idea. Just watch Linus introduce git at http://nl.youtube.com/watch?v=4XpnKHJAok8 whenever you’ve got the time.

Leave a Reply