Why is Drupal still using CVS and how can I help change that?

This question frequently comes up on the mailing lists, on IRC, and so on. For many developers, CVS is difficult to learn, clunky to work with, and misses many features of more modern revision control systems. This document is a summary of the mailing list discussion at http://lists.drupal.org/pipermail/development/2008-July/030595.html.

What's the next step in version control?

The two dominant arguments in the community are:

1. Drupal should move to Subversion, which is a centralized version control system like CVS but easier to use and addresses a number of CVS's design flaws, such as adding the ability to rename files easily.

   Pros

   • Many existing Drupal shops and developers use Subversion for their own projects, so there is a lot of community knowledge about Subversion.
   • The documentation is excellent.
   • The Subversion community support is also excellent.
   • Supports https authentication, which is far more secure than CVS's pserver.
   • As another centralized version control system, maps easily to what developers already understand about CVS.
   • Would no longer need to burden the repository maintainers with trivial requests like moving, renaming, and removing files and directories.
   • SVK provides a decentralized version control system built on top of Subversion, for "power" developers. While this project looks a bit stalled, git-svn and bzr-svn exist as well.
   • svn:externals allows for Drupal shops to easily pull the desired releases of modules directly from Drupal.org, and has potentially positive implications for installation profiles as well.

   Cons

   • Doubts over whether or not moving from CVS to SVN will provide enough benefits to warrant the massive effort.
   • There's no difference in Subversion between branches and tags; developers can commit to either freely. However, this can be worked around with SVN pre-commit hooks to emulate CVS's tag (once it's committed, that's it) behaviour.

2. Drupal should move to a decentralized version control system, such as Mercurial, Bazaar, or Git. This would allow developers to create their own branches of core and contributed modules to play with, and also enables offline committing and patching.

   Pros

   • Would make development of major core re-architecting features such as CCK fields in core, database abstraction layer rewrite, etc. much easier to manage, as developers' external SVN repositories would no longer be required.
   • Would allow for core development to use the concept of "subsystem maintainers" where there were multiple core committers each with a branch of Drupal corresponding to their area of expertise (Form API, Menu system, etc.) Note that the above mentioned SVN pre commit hook script makes this possible as well.
   • Developers can commit their changes intermittently on their own branches, even off-line. But see SVK above.

   Cons

   • Seriously drastic changes would need to be made to the core development workflow to take advantage of a distributed version control system.
   • Learning curve for contributed module and theme maintainers; very little of what they understand about CVS carries over with a distributed system.
   • Although many developers in the Drupal community use these systems, the majority do not. Therefore, it could be challenging to train community members on how to use a distributed source control system.

Because of the major cons and little pros (for our community at least) associated with distributed version control systems, a move to one of these is unlikely, unless it provided a CVS or Subversion front-end for the 99% of our contributors whose version control needs are simple.

Why hasn't it happened yet?

There are many reasons that Drupal is still using CVS:

• Many of our developers (especially themers) are on Windows or Mac and need GUI clients. TortoiseCVS and TortoiseSVN are two such clients. Distributed revision control systems tend to lag behind in this area and the related area of integration with popular integrated development environments (IDE). Note that this obviously changes as time progresses and now most distributed GUIs have some sort of GUIs for most platforms.
• Project module is heavily tied to CVS. Project module, which powers Drupal.org's download system, was designed to work with CVS. Since then, we have the Version Control API project, which adds a layer of abstraction on top of a given version control system, and there are back-ends for most of the major systems. What we need now is a bridge between Project and Version Control API modules. A well-documented to-do list about this is available at http://groups.drupal.org/node/8102.
• Release scripts, etc. need to be re-written. There are a lot of scripts found at http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cvslog/xcvs/ that need to be re-written to work with the version control system of choice.
• Videos, documentation, and other training resources need to be updated. Drupal currently has an extensive archive of videos and documentation related to CVS. All of this needs to be updated to the version control system of choice, as well as a large body of helpful people to be on hand to provide real-time support to developers in #drupal during the migration phase. If Drupal moves to a distributed version control system, this becomes even more imperative because a lot of the existing knowledge developers have about how version control systems work gets tossed out the window.

I'm ready to dig in and help move this forward!

Great! The best place to coordinate would be the http://groups.drupal.org/revision-control-systems and http://groups.drupal.org/issue-tracking-and-software-releases groups.

You should work on getting a large team of people who share your passion for moving Drupal to another version control system. You'll need people who can do the following:

1. Revision control gurus who can handle the migration of the CVS repository to the new format, authentication and access control setup, etc.
2. Coders to handle converting various back-end scripts, such as Project module integration, pre-commit hooks, and so on.
3. People passionate about training who can help update the existing documentation, videos, etc.
4. A support team to be on-hand in #drupal and the issue queue to field questions from contributors as they learn the new system.