From BioPerl
Jump to: navigation, search

Someone will write here why they think it is important for the BioPerl project to make the switch from CVS to SVN.




  • When set up properly, do not need to give SSH access to users.
  • Better integration with IDE
  • The status command's output is actually readable. To get similar with CVS, one must use cvs -n update, which is
    • confusing (because you're not updating, you're checking the status of your working copy)
    • and dangerous (because if you forget the -n, you've just synced with the repository and possibly clobbered your local changes).
  • Along the same lines, svn update does not clobber your local changes as happens in CVS. 'Pulling' changes from the repository does not imply 'pushing' local modifications. Likewise, committing changes on one file does not automatically update other files in your working copy, even if they've changed in the repository.
  • Atomic commits.
    • If you realize you want to abort a commit that's in progress, you can ctrl-C with no consequences — the repository will be totally untouched.
  • Arbitrary metadata.
  • Versioned metadata.
  • Binary diffs.
  • Most of the interface is identical to CVS, so switching over doesn't require learning an entirely new set of commands.
  • Working with branches are far easier as they are simply just another directory structure on the filesystem
  • Directories, renames, and file meta-data are versioned
  • Most network protocols use diffs. E.g. With svn, diffs are transmitted from client to server on commits, so the cost (time/bandwidth) is proportional to the size of the change made, not the size of the file/repository. Even on binary files.
  • This is only my opinion, but since svn seems to be the way of the future (e.g. Sourceforge has switched to it), as time goes on people new to BioPerl are likely to be more familiar with svn, and therefore more likely to use BioPerl and more likely to contribute. --Dave Messina 10:14, 28 June 2007 (EDT)


  • No distinction between tags and branches
  • Repository is much larger
  • If database is corrupted can lose revision information?
  • Since tags and branches are dealt with in the same way as the trunk - no special treatment i.e. as a directory tree on the filesystem, it is possible for someone to inadvertently/purposely edit/change files in the tags directory - something which should be avoided and addressed such as to minimize this risk.
  • Not as fast as CVS.



  • Already set up, more supported client software


  • Requires SSH accounts for all developers
  • Commits aren't truly atomic.
    • If something goes wrong during a commit (and it's usually a big commit), part of the repository may have been changed, and another part may be out of date. Reconstructing what happened and redoing the commit is no fun.

Other Arguments

Other people's reasons gleaned from Google

Personal tools
Main Links