Once again, another open source project has dropped Concurrent Versions System (CVS) for Subversion (SVN). Both CVS and SVN are open source version control systems used mainly by developers involved in various software projects. This time the project is phpBB, a forum application.

We like to announce the switch from CVS to SVN for our repository management and source control. Within this step, we also set up a new home for phpBB development and phpBB related projects. At the moment only phpBB itself is listed and only repository management handled there. Within the next months we will enable more and more features and move internal projects as well as hopefully other public projects to the new home. [Link]

Although I'm not much of a developer, I've been interested for some time in why a project has picked one version control system over another. In part this is because I recognize revision control is something my own employer need to do better, not just for the larger projects but even the "local" non-enterprise projects I often found myself involved in.

Except for some Python programming, I've done very little software development this decade with most of my efforts in the 80's and 90's (BASIC, Pascal, Perl, Tcl, etc). Those that know me know I've wanted to dig more into PHP and Ruby, but I have been distracted by one sorry excuse after another.

For work and my status as a Drupal Developer Wannabe I've also been making the effort to learn more about revision control. One issue I have is that at work the consensus has been to use Subversion for version control while the Drupal community prefers CVS. It shouldn't be too difficult to master both version control systems, but for whatever reason my brain cells in that department haven't switched on.

Luckily, I just came across a nice how-to tutorial by Nick Sergeant (first time I've come across his name too).

After reading the Pro Drupal Development
book, and becoming a recent Subversion junkie, I’ve learned to do all
of my Drupal and Contributed Module management through a combination of
CVS and Subversion.

Through this post, I’m going to attempt to take you through all of
the steps of managing your Drupal installation as well as any
contributed modules you may need to utilize.

The tutorial is called, Painless Drupal revision control with CVS and Subversion. This how-to by Nick Sergeant should be a big help for the Drupal Developer Wannabe that would like to or needs to do their work in Subversion and not CVS. As I'm no expert, if you see any corrections that need to be made to the tutorial, please leave a comment over at Nick's blog.

I spend too much time sticking my nose where it likely doesn't belong.  Check out Dries comments toward the Drupal project using CVS and my own comments somewhere below his.  I argue that SVN is the correct choice.  I'm unqualified to really know the answer.  Sort of like me telling Bill Gates that dropping the current Windows code and starting something new would be better for Microsoft in the long run.

A couple days ago, I was checking up on the status of Wordpress 2.1, which is supposed to have exciting new features like pseudo cron and spell checking. I came across Wordpress's defect/feature management system, Trac. Just to be clear, Wordpress isn't the author of Trac."

CVS services (including CVSup and CVSweb) will be permanently unavailable on Fri Mar 16 03:00 UTC 2007. The source code repositry has been moved to SVN.

If you require the CVS repositry, please get it by CVSup till that day.

• Pragmatic Version Control: Using Subversion (The Pragmatic Starter Kit Series)(2nd Edition)
• Red Hat Fedora Core 6 Unleashed
• PHP and MySQL Web Development (3rd Edition) (Developer's Library)

Congratulations to the Ruby language folks for converting their CVS repository over to Subversion (SVN). From what the "experts" tell me, it is not easy moving your developers over to another version control system. At least that's what was hinted when I asked the question, CVS or Subversion?

The difficulty of moving a project to a different version control system likely has just as much to do with cultural issues as it does with technical issues. To ask a developer to use a version control system when they never have used a version control system before is difficult enough. To ask a developer to spend a day or two to learn a new version control system over the one they're currently using is three times more difficult.

For the organization that I work for, we've settled on SVN. A lot of the developers in our field offices are used to programming alone, thus most of then have never used a version control system. I believe we'll find SVN is the right choice for the new projects we're starting up.

In case you missed it, there are a couple articles recently posted here at CMS Report that are drawing some attention.

In the first article, Version control: The CVS or Subversion question, I posed the simple question of which version control system should I use for a new project my employer has involved me in. A number of people have already responded so far and I thank them for their input. Most commenters spoke favorably of Subversion and recommended it over CVS. While people understood why large open source projects such as Drupal may not abandon CVS they didn't recommend CVS for new projects. So far Subversion has my vote.

In the second article, Headaches from security updates for Firefox and Thunderbird, I pointed out some of the struggles that exist in deploying my favorite browser and e-mail client on an enterprise network. While the comments so far have been few, Asa Dotzler of Mozilla was kind enough to stop by and give his two cents worth. He's been around since the Mozilla suite days and a key player at Spread Firefox. Spread Firefox is a Drupal site even non-Drupal fans should recognize. I'll let Dotzler's comments stand on their own without further comment. Needless to say, there is a reason why I like the Mozilla community. Even when those guys disagree with you they still hold value to your opinion.

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:

"Mambo re-opens SVN - Around v4.5.3 the Mambo Foundation migrated the Mambo code from the old CVS repository to a new Subversion (SVN) code repository...."

[MamboServer.org]

"Gallery has switched its revision control system from CVS to Subversionto take advantage of Sourceforge's latest offering. Subversion is faster and more featureful than CVS and should increase our development velocity, which means that you get a better product, faster. For those of you who are using Gallery via CVS, we've created a page in the Codex that explains how to use Subversion including how to migrate over from CVS. If you don't know what CVS is, then you won't have to worry about this."

Complete Story