Skip to main content

Version control: The CVS or Subversion question

By Bryan - Posted on 01 September 2006

I have been keeping an eye lately on two version control systems, Subversion (SVN) and Concurrent Versions System (CVS). My sudden interest in version control is due to a project team I'm on for my organization. The team is in the early phases of project management and needing to pick either CVS or SVN. At this time we are leaning toward SVN.

I'll admit, I have some hesitancy to commit to SVN. The reasons for my hesitancy likely has more to do with personal reasons and likely less organizational needs. Some of my favorite open source project, including Drupal, are still using CVS. I'm not sure we'll be using Drupal for this project, but there are bound to be some open source applications we end up using where the code is still stored on CVS. If the developers of the poen source applications are using CVS, perhaps there is some validity in choosing CVS over SVN.

Regardless, it is hard to ignore the popular trend of moving to SVN for some of it's more "modern" features (so I've been told). A number of developers in my own organization have also mentioned there own projects either using SVN or in the process of moving from CVS to SVN. However, it doesn't seem to be an easy decision as I have seen a number of posts lately indicating the internal struggles that go with making such a decision. For example, Paul Reed from Mozilla, had this to say about a possible move by Mozilla to shift their code off of CVS and on to SVN:

Is the Mozilla Project switching to Subversion? There have been many discussions in the past few months about the version control system that the Mozilla project entrusts its code to. It's safe to say there's a desire from most of the community to thank CVS for taking good care of our source code - for the most part - and move into the 21st century...

...It's a project-wide discussion...But no decision has been made on which version control system to switch to, nor have any concrete plans (schedules, etc.) even been considered.

The decision by the project team I'm on to use CVS or SVN will eventually come with time. Meanwhile, I'll keep an eye on my own personal favorite CMS, Drupal, and see where their developers might be headed with regards to version control. If my organization does decide to go with Subversion...as a personal project I may see what I can do to help those in the Drupal community build better ties between Drupal and Subversion through modules. I just wish I wasn't lousy at programming and could help more than I do.

By the way, I'm open to any input others have on the subject of version control. This discussion of course can include other version control systems besides CVS or SVN.

 

Comments

#1 trac

Joe's picture
Submitted by Joe (not verified) on September 1, 2006 - 1:41pm.
Do you plan to use trac for tickets and other project management? It talks to svn nicely. I understand that there has been work done to make it use cvs as well but have no experience that way. trac can act on tickets using the commit message: http://trac.edgewall.org/wiki/TracFaq#ca... To complicate things for you, Drupal uses Bazaar-NG as well as cvs - http://drupal.org/node/45368. This helps decentralized development. have fun, Joe

#2 Have not decided if we'll be

Bryan's picture
Submitted by Bryan on September 2, 2006 - 9:52am.

Have not decided if we'll be using trac or not. Some are pushing for egroupware for the project, but since I have never used it before I can't really comment too much on it. My impression is that egroupware might help in some of the business needs, but fall short on some of the IT needs. As I said we're in very early stages and just throwing ideas around.

I like what I see in trac. My groups would be extremely comfortable with a Python application, the language used by trac. Though we have been hopeful to most of the Web applications under PHP.

#3 eGroupware for project management

Joe's picture
Submitted by Joe (not verified) on September 2, 2006 - 10:52am.
I previously used eGroupware for my software projects and support. Mostly for the timer. It was nice to automatically attach time to project tasks. But when the project manager rewrite was underway this feature was not in place when I moved over to other tools. eGroupware is strong in the administration part of project management. TTS was just recently rewritten though and haven't done more than try to test the demo. I still use egroupware for knowledgebase and wiki. For other reasons we've mostly moved to Basecamp for team related stuff and trac for software development stuff. Wish I had another timer solution though. I liked KDE's implementation - you could have it start/pause when you entered and left a particular desktop. But I use too many different machines to have something stored on a local machine ( and use mostly xfce and Mac OS X). Joe

#4 I remember reading through

dalin's picture
Submitted by dalin (not verified) on September 1, 2006 - 1:50pm.
I remember reading through some discussions about Drupal and and versioning control systems. The general consensus was that it would be nice to switch to SVN. But it's not just a mater of moving the files from one repository to another. The project module is tightly integrated with CVS, and hence drupal.org is as well. It will take a lot of work to change the project module to use SVN. And although it would benifit the community as a whole it doesn't get addressed because no one feels enough motivation to attack the project as an individual. It's just one of those areas that is a challenge due to drupal being a FOSS project.

#5 SVN all the way, don't think twice, it's all right...

Victor Kane's picture
Submitted by Victor Kane (not verified) on September 1, 2006 - 9:38pm.
SVN offers a great many benefits, we are using it in many large projects. Basically, the revision is automatically an (economic) snapshot of the whole repository; but the main benefits are a much simplified and yet more powerful set of commands, plus binary files are versioned in a much more efficient manner, plus you can easily move and copy files very economically (pointers) within the repository tree; plus api for many scripts; plus easy hooks for pre and post processing... excellent documentation (for the windows based TortoiseSVN client also), use of Apache2 authentication, with WebDav for browsing with Firefox directly... and the list goes on... Of course, I can understand the prospect of changeover from CVS to SVN a daunting task with large projects involving a gigantic codebase and a large base of automation scripts, etc. (like Drupal) and I can understand that not being the number one priority, as it will be a lot of work to actually do the changeover, even tho everyone agrees it's worth it. But for a new project, don't even think about it, SVN all the way. (In tools like Eclipse, for example, Subeclipse works very well indeed, as does the TortoiseSVN for your windows based crew.)

#6 Go SVN

Larry Garfield's picture
Submitted by Larry Garfield (not verified) on September 1, 2006 - 11:03pm.
SVN is the heir apparent to CVS. SVN was written because CVS' internal code is a disaster. It's an amalgam of very old stuff kinda piled together. That's the main reason the SVN guys started writing SVN. (I've me them; nice folks.) SVN really is the next evolution of centralized versioning. It doesn't do anything ground-breakingly new, feature-wise (aside from binary-safe diffing), but that's because centrally versioned projects are a well-established problem space. If that's what you're looking for, SVN is what you should be looking at. CVS lives now on inertia; it's non-trivial to move large projects from CVS to SVN, especially if there's ancilary code and infrastructure setup (as in Drupal). For a new project, though, it should be a really easy choice. SVN is where everything is moving, so skip the difficult migration later and go with SVN now. It's well-tested and battle-ready. That said, both CVS and SVN are centralized repository models. Distributed model VC systems (Bazaar-NG, git, ark, etc.) are an entirely different creature, about which I know rather little. I don't know if that's something you are considering for this project, but Subversion is the emerging standard for centralized repositories.

#7 Gallery

jacauc's picture
Submitted by jacauc (not verified) on September 1, 2006 - 11:56pm.
Well, I'm not too sure which one's best myself, but I know that Gallery2 (http://gallery.menalto.com) recently moved over to SVN. Probably drupal will move over to SVN in the future as well. It seems to be a trend. SVN sounds much more powerful, and I guess at some stage, CVS will just not cut it anymore. ...Just another example

#8 Great comments so far. It

Bryan's picture
Submitted by Bryan on September 2, 2006 - 9:56am.

Great comments so far. It really does seem the comments suggest for a new project we would be crazy to to choose CVS over SVN. Any from the pro-CVS crowd have an arguement as to why I might not want to choose CVS over SVN with a new project?

 

#9 SVN by choice

Vinay Yadav's picture
Submitted by Vinay Yadav (not verified) on September 6, 2006 - 1:22am.
You can read a very detailed comparision of CVS vs SVN at http://www.pushok.com/soft_svn_vscvs.php Vinay Yadav PHP specialist http://www.vinayras.com
Bryan's picture

About this CMS Enthusiast

Bryan Ruby is the owner and editor for CMS Report. He founded CMSReport.com in 2006 on the belief that information technologists, website owners, and web developers desired visiting sites where they could learn about content management systems without the sales pitch.

Outside of his late night blogging hours, he is the Information Technology Officer for a field office in the federal government. Away from the computer he enjoys his family, bicycling, camping, and the outdoors.