Article:		The New Breed of Version Control Systems
Subject:		Not so fast...
Date:		2004-01-30 01:37:18
From:		shlomif
Response to: Not so fast...
As far as developers are concerned, they won't have any problem adjusting to a different version control system that is compatible enough with CVS. As for development tools, integration with them is a nice thing, but not a must to use such a tool. (you can always use the command line). Having used CVS before and using Subversion now, I can tell that I find CVS extremely painful to use now. I wouldn't recommend it for anything. I think we will eventually see CVS superceded by something else entirely, and one is advised to join the switch sooner than later. CVS - Die! Die! Die!

Showing messages 1 through 2 of 2.

• Not so fast...
  2004-02-26 12:16:05  dettifoss [View]
  
  
  "CVS - Die! Die! Die!" ? ? ? Maybe you should have used this as the title to the original piece: at least then your agenda would have been clearer.
  
  So the point of the original, then, was not to present a balanced and informative comparison of available VC systems, but rather to stick it to CVS?
  
  That's certainly what came across :-) Shame the title that was so misleading...

• Not so fast...
  2004-01-30 03:43:02  sanchonevesgraca [View]
  
  
  Thank you for your article. It provided an overview of SCM systems suitable for open source projects. I favour Subversion for the following reasons. I previously used CVS and a year ago I switched to Subversion. I am not involved in its development but I can write the following from a user perspective. The fact that CVS has an overwhelming presence in open source projects does not mean that the status quo should prevail. The lack of move operation for files and directories while keeping history is definitely a strong reason to migrate to a new SCM system. Also very important is the support of HTTP protocol. Apart from it ubiquity, it allows developers working behind a company firewall to access remote repositories without violating the firewall policy. Arguably, a natural replacement for CVS is Subversion, because of its Apache license and the fact that the project team developed it with the clear purpose of replacing CVS (at the beginning of this week, Subversion release candidate 1.0 was published; the Apache Software Foundation has since last year a preliminary Subversion repository). The Subversion SCM concepts, while not trying to replace all other SCM systems, has a powerful paradigm. Everything is a directory or file, and most SCM patterns can be applied following a few naming conventions for the main project directories. Also note that the svn commands are much cleaner and consistent than cvs, making the interaction from a Unix or DOS shell quite easy. Last but not least, the Subversion system was designed from the outset with both Unix and Windows in mind. Native support for Windows is very important because it forms the bulk of desktop systems, in and out of corporations. In this respect, the GNU Arch developers could learn a bit more about software engineering from Subversion, since they developed a system for Unix and still consider Windows as an afterthought, which is unrealistic.