By Wesley Tanaka on

So in spite of the risk of starting a flame war, I'd like to request this:

"Please convert drupal to using subversion for development"

Comments

larssg’s picture

larssg commented

There have been a lot of discussion on this topic for as long as I remember - with lots of flamewars. There are many reasons for not moving away from CVS, the main one (AFAIK) being that drupal.org has a lot of infrastructure set up to handle CVS. It would take quite a lot of work to convert to a new system.

Also, I don't think it has been established that Subversion is the best alternative to CVS...

UncleD’s picture

UncleD commented

There's other alternatives, some of them are even costly. A nice new open source one is mercurial.. but what is so bad about CVS that is currently running? Will it make huge improvements to productivity and drupal developments? I don't forsee that.

shap’s picture

shap commented

I don't care if drupal.org switches or not, but to answer your question:

  • hg offers a distributed development model. This may or may not matter for drupal.org, but it does provide a way for developers to operate on multiple branches even when they cannot connect to a central repo.
  • hg offers branching and merging that works. This is surprisingly hard. It was a major goal for OpenCM as well, but the hg team beat us to a working network interface. The rest of OpenCM has some security features that are useful, but they may not be all that compelling for general users. We have other things to do, so it looks like OpenCM will be abandoned.

There are, of course, other SCM systems that do some of this as well. Git comes to mind, but the general consensus seems to be that it is hard to learn and use, and not as customizable as hg (which, aside, is both a feature and a curse of hg).

As I say, I don't really have an axe to grind here. What I really want is a mercurial integration plugin similar to the one for CVS, so I may just go off and build one.

Setting aside the question of mercurial in particular, there is one major advantage to distributed SCM systems: they get rid of patches. The problem with me doing a change and sending you a patch is that the patch is busted by the time you apply it (because your version has moved). If I instead send you a change object that has its relationship to the global distributed change history preserved, it becomes much more likely that you can apply it successfully, and the full history of the change is preserved. This actually is a major benefit, but it is hard to understand the impact without seeing it in action.