Open Source for many developers means getting the hands dirty in many projects simultaneously sending patches here and there as they polish their own way through the code to make sure the bug encountered today will not pester anyone in the future. Everybody seems to be interested in reporting the bugs and sharing patches, but in reality it doesn't happen too often, mostly because of lack of time necessary to contribute. Following modern enterprise tendency to define various measures and estimates let me call this parameter as Time-To-Contribute value. TTC is directly influenced by such factors as activity of developers and availability of the code as well as usability and knowledge of development tools.
It would be interesting to get deep into the details of code contributions, but to keep the long story short and justify the title let's compare SVN and CVS. These tools provide access to source code and poor decision may affect developers experience and desire to contribute in the future. This post based on RFC submitted to PHPDOC community a year ago, which may be useful for other conservative CVS parties out there like MinGW
Facts only.
++++ Accessibility:
CVS usually blocked by proxies (needs dedicated port)
SVN works over HTTP and HTTPS via WebDAV
CVS doesn't work behind a proxy
SVN works with proxies
CVS checkout is complicated, it is hard to remember all the prerequisites
cvs -d :pserver:cvsread@cvs.php.net:/repository login
cvs -z3 -d :pserver:cvsread@cvs.php.net:/repository checkout -P phpdoc
SVN project checkout command is easy to remember
svn co http://svn.php.net/repository/phpdoc
CVS is complicated to learn
SVN has a perfect book
CVS is abandoned by developers
SVN is supported
++++ Security:
CVS password is transmitted over network in cleartext with simple rot13-like translation
SVN works over HTTPS, supports Apache authentication schemes
++++ Usability:
Command set is mostly the same
CVS fetches previous revision online to build diff of changes
SVN builds diff offline
CVS takes twice less disk space
SVN stores full copies of checked out files for comparison
CVS screws linefeeds
SVN doesn't screw linefeeds
CVS is file based - history is separated for each file
SVN is atomic - modification of group of files is a whole
CVS maintains independent revision numbers for each file
SVN revisions are global for repository
CVS leaves deleted directories in repository tree
SVN keeps directory tree tidy
CVS has convenient concept of branches/tags
SVN branches/tags are just directory copies in repository
CVS branches/tags concept is complicated
SVN branches/tags are easy to understand
I think that for the most of us the choice is rather obvious if there are no practice to use $Id$ to track how many changes a file underwent since last time, or if people are not too addicted to CVS branches. Nevertheless there are still many projects that use CVS and the true reasons why people do this are: old habits, absence of time to learn something new and dependencies on CVS in hard-coded legacy scripts. Of course, laziness is also a reason and it's funny that this laziness sometimes pushes to seek more convenient tools.
I have used CVS and SVN in eclipse. The main problem with SVN in eclipse is that it is not integrated, it is slow and plugins work horribly bad. For example, it is a headache to delete or rename a package in a Java project, and if you rename a file, you must commit before you are allowed to rename once again (ie you reanmed incorrectly). I don't like much the idea of global version. The best option is to have versions for each file, and to be able to tag a global version when needed In SVN is not possible to create tagged versions inside a branch. The only option is to create another branch which is unpleasant and difficult to manage. SVN has some improvements over CVS, it's true, but the more I use it, the more I dislike it.
ReplyDeleteThat's because initially Eclipse was written for CVS providing many convenience features for those who had enough with CLI interface. Now there are even more advanced version control systems like Mercurial, Git, etc. and they stand out from traditional Eclipse version control workflow even more. The dialogs and controls should be redesigned accordingly to provide enjoyable experience, but at the same time they should be familiar for people switching from CVS to avoid confusion and delays.
ReplyDeleteWhat flavour of SVN Eclipse integration do you dislike more? There are http://subclipse.tigris.org/ and http://www.eclipse.org/subversive/ I know people who use TortoiseSVN even though with Eclipse plugins are installed.