While distributed source code management tools like Git, Mercurial, Monotone and Bazaar (which some Drupal developers use) offer advantages over CVS or SVN, they are not as accessible or well-supported. Drupal developers and Drupal designers are not Linux kernel hackers, and for many of them CVS is the biggest barrier to entry. Without desktop integration for both Windows and the Mac (like TurtoiseCVS or MacCVSClient offer), I don't see how we can migrate away from CVS without leaving half of our community behind ...

Not to mention the fact that our entire release management system is built on top of CVS. It would be a lot of work to switch that to another system.


yaph (not verified):

CVS and SVN are very powerfull tools for source code management and are widely used by professional. I can't agree with Linus that CVS and SVN are useless.

Bart Braem (not verified):

A question from someone with a growing interest in Drupal: why do you still use CVS? I've seen quite a lot of projects make the step to Subversion (and so did we for all our internal repositories). I've found a thread discussing Subversion on the Drupal development mailing list but it was not really clear.

Groeten uit Antwerpen,

Gábor Hojtsy (not verified):

Bart, the answer is very simple. We have a lot of tools (project management, packaging, commit tracking and so on) built specifically for CVS, as Dries mentioned. Unless these are migrated to a version control system agnostic model, and keep being tied to CVS, we cannot migrate. This might not happen all at once.

Luckily this years Google of Summer of Code seen Jakob Petsovits (https://groups.drupal.org/user/3265) applying and getting accepted to attempt this transition, and he is going nicely so far. Do not expect results in a few weeks though, there is a lot to do here.

Anonymous (not verified):

Well that is one of the drawbacks of building entire systems/toolchains on top yourself. I prefer to keep things simple and accept somewhat less integration & automation, thereby remaining flexible and not get tied in to particular tools or even versions of tools too much.

Alas, always where you see too much role-specialisation (e.g. people who have a dedicated role for release mgmt etc) you see people taking it too far and confuse goals and means.

Mohammed Sameer (not verified):

I agree that CVS is still fine. I was using it for my personal repository until a few weeks ago when I had to convert to SVN for one simple reason: I want to access my repository even if I'm behind a proxy. I can't use CVS behind the proxy but SVN+Apache'd do fine.

I'd really like to see a Drupal SVN repository even if it's an unofficial mirror (I'm welling to contribute time and efforts) just to solve the proxy problem. (I guess a lot of people are having the same problem? I don't know.)

BryanSD (not verified):


Speaking as a non-developer...in my organization we've been working very hard in bringing version control to our developers. We considered a number of version control systems (even propriety) and settled over SVN.

Why not CVS? While CVS is still a decent version control system, the synergy from almost every developer we talked to was toward SVN. They only justified CVS for "old projects" and not for anything they would begin today. In other words, my impression was CVS was of the past and SVN was the present/future.

Why is the interest in SVN important to recognize? While Drupal is doing well with CVS...what happens when the majority of "new" open source developers know little about CVS but are very comfortable with SVN? I'm going to argue, that they'll be less likely to share their code with Drupal.org. Just as you're worried that by moving away from CVS will leave "half of our community behind" you also have to ask whether it will "keep half a community" from joining Drupal.

At my work, our primary programming lanaguage on our operational systems are Python and Tcl/Tk. Both good languages, but our contractor has insisted migrating us over to Java. Why? Although the majority of our in-house programmers know nothing about Java...the majority of developers are skilled in programming with Java. In other words, we have a better chance of bringing in new talent by picking a programming language with the biggest talent pool. While it is a lot of work for moving our programs off of Tcl or Python...we have a better chance of finding good developers to support our our legacy and current programs by moving them over to Java. This is our hope of course...the future is always unpredictable in IT. :-)

Dries, I argue that the question is not what version control system do Drupal developers want to use today, but what version control system would Drupal developers want to use tomorrow? I don't know the answer to the question for Drupal...but I do know the answer for an increasing number of open source projects. SVN.

Gábor Hojtsy (not verified):

Doh ... Maybe read the post again?! Dries compares "Git, Mercurial, Monotom and Bazaar" to "CVS or SVN". CVS and SVN are very close to each other, and have their tools for major OSes without leaving half of the community behind as Dries explained. On the other hand, "Git, Mercurial, Monotom and Bazaar" offer great advantages to developers (as Dries notes, some high profile Drupal developers already use private Bazaar repositories), they are not accessible to (more then) half of the community, and put a higher barrier to entry. You ended up with SVN for a similar reason probably and not Git, Mercurial, Monotom or Bazaar.

The topic of this post is not to debate migration from CVS to SVN.

Bèr Kessels (not verified):

The question, indeed, should not be SVN or CVS. SVN is really nothing more then a less sucking CVS. Real improvement takes a few steps ahead, being DARCS, GIT, or BZR indeed.

SVN will hardly make things better, but will take the same bumps as those "few steps ahead". SVN is just less bad then CVS. For real improvement we should look at the distributed ones. But, like Dries and Gabor point out, many, many severe humps need to be taken.

JohnAlbin (not verified):

While a lack of good GUI tools is definitely a barrier to entry. So is CVS’s archaic history and convoluted CLI options.

But, I can quickly see one serious problem with Mercurial, Monotom and Bazaar. They are all pre-1.0 software. Subversion has been post-1.0 for nearly 3.5 years. And it finally has decent client-side GUI tools.

And while Subversion and CVS are most similar, I would consider SVN about half way between distributed version control systems (like Mercurial, etc.) and CVS. It may not have full working-copy-side revisions, but it does have a working-copy-side BASE and easy file and directory move/rename features.

If it takes Mercurial et al. 4 years to get nice GUI tools, it's clear Drupal will need to move to SVN in the interim (by first converting the code base to a “version control system agnostic model.”) I look forward to the journey.

Jay Batson (not verified):

At the last company I started (http://www.pingtel.com), we moved from a closed-source to open-source model. In the process, when we went through the analysis of which source code control system to use for the new (public) code, we did an extensive evaluation of the choices. While this evaluation is now several years dated, we decided:

  • CVS was too creaky (though, notably, our existing internal code was all in CVS, and moving from it required _us_ to shift our toolchain);
  • SVN was broadly supported, and had some technical advantages over CVS;
  • As John mentioned here, some of the other tools showed promise, but lack of maturity and limited tool support made them poor choices.

So I'm replying under _John's_ comment because from my perspective, that same analysis still applies: CVS isn't it, the new tools aren't it, and SVN should be it. It _is_ painful to move; but the long-run benefits are worth it, IMHO.

(I'm less sanguine than John is about the ability to create a "version control system agnostic model.")

dww (not verified):

Further reading:

https://groups.drupal.org/node/4313 "Git scrutinized" by jpetso, the SoC student working on the revision control abstraction stuff for drupal's project.module.

https://groups.drupal.org/node/4281 -- initial progress report by jpetso on his work so far.

Re: revision control agnostic code: I think the not-so-tied-to-CVS stuff will be done very well, and relatively speaking, quite soon (probably before the official 6.0 core release). That said, I'm still not convinced switching to SVN is yet worth the trouble for the Drupal project. But, that's not the point of this post, now is it? ;)

From what little I know of it so far, git definitely seems appealing to me as a revision-control freak. ;) I haven't watched Linus's video above, but I will when I have a free hour. However, it certainly seems to have a reputation for being even more complicated and cryptic than CVS, even if the added complication is caused by majorly improved flexibility and functionality. As the person who fields the vast majority of the support burden of using CVS on the Drupal project, and given how little the average Drupal developer seems to know about revision control at all (much less the specifics of any given tool), I'd really fear switching to something even more complicated and difficult to navigate like git.

Furthermore, while every-workspace-is-a-repository is great for working off-line, that also means you'd have to checkout the entire contrib repository to do anything with any part of it... unless we moved to separate git repos for each project, which is another nightmare of its own...

Also, keep in mind that (for fear of the developers messing it up) Drupal never really uses any of the more advanced revision control practices like merging branches, so improvements in functionality like that don't matter much for drupal.org itself. Granted, if we had a tool that made merging vastly easier and better, we might actually let people use it. But, by switching to a more complicated tool that makes the advanced operations easier, we're just raising the bar for the average Drupal contributor who can't even seem to grasp the (IMHO) simple concept of a branch in the first place. :(

Final note (meta comment about this thread, not a response to the thread itself), as I've repeatedly mentioned in the past, I'm a little worried about putting code into core that ties directly into our usage of CVS, since that binds us to a given revision control tool. However, exactly that is shaping up to happen as we move the update_status.module into core, since (at the continued request of the deploy-from-CVS crowd of Drupal power-users), I've kept adding code to update_status.module to handle sites that deploy from CVS more gracefully. :( In the past, I wasn't too worried, since it seemed like Drupal wasn't planning to switch tools for a long time, but the existance of this post is making me nervous about this point. Any input on this would be welcome.

sepeck (not verified):

Why are you catering to the 'deploy from cvs crowd at all? They want to be power users, then they need to deal with that. If you tie us to a given system in the initial excitement of 'neat feature' then you we will all have a much more complex path forward.

Why not have the 'tie to cvs' portion of the update module code be a 'contrib' module?

dww (not verified):

Seems we're on the same page. ;) I was thinking more about this and decided to split out all the CVS-specific code to another module, which would stay in contrib while the rest of update_status moves into core. Was just coming back here to post the link for interested parties and saw your reply. ;)

Anyway, here's the issue:

Comments there, please. There are some open questions about what to call this new module, and also how the hook_get_version() I'm planning to introduce should actually work (and be called, for that matter). What's there in the current draft of the patch is rather hackish and crude -- this needs more thought before it's core-worthy.


p.s. See also https://www.drupal.org/node/124661 if you're interested...

morphir (not verified):

How many are left behind because of the fact we use CVS and not SVN? That is a valid question as well. Maybe a poll/survey could provide some answers to this question?

For a couple of years now, members of the community have foreseen that drupal would get forked, hence the needs for different types of distributions (media, school, churches and what not). Now that drupal will offer different distributions we prevent forks from happening, I think. However, I see that maintainers of this distributions could benefit from using git hence the revision-control system it offers.

The trustee network that Linus talked about, was another interesting point.

Today, I have no opinions on whether we should stick to CVS, jump to SVN or choose GIT as our future revision-control system. But I know we do need to make things simpler so the "drop-in" developers can easy(ier) commit their code, without going through handbook hell.

about git:

git do offer a web interface: http://git.kernel.org/
git is just POSIX-compatible(linux and mac osx): http://www.spearce.org/2007/01/git-gui-screenshots.html

for windows users: they would need to install Cygwin. Wait, there is hope: http://www.mingw.org/

git may not be most obvious solution today, but maybe for tomorrow.

Anonymous (not verified):

Well, Linus has strong opinions, that's true. But then again he's saying all that from his own point of view, which is the kernel development. And I believe him when he says that CVS/SVN/whatever is completely unsuitable for the things that *he* has to do. He has huge requirements as his task is large and complex.

CVS/SVN/whatever might be very well suitable for someone's small project, no question. But that's not what you should look at when you design a SCM. Small people are probably happy with whatever anyway, but it's only with a big project and complex situations that you will be able to tell the difference between two SCMs and see weather they're worth anything or not. (In fact, I am such a small person, and when I first discovered CVS, I was very happy and thought it's great. Then I went to SVN and was happy and thought it's even better. Small people are easy to amaze. And they should keep their mouths shut when the big people make decisions or express strong opinions. :) )

That being said, git is indeed the work of a true genius! It's simple but still amazingly powerful and I'd prefer it over CVS and SVN any time. Linus writing git also proves that he doesn't just bitch around with cynical and strong opinions, but also is able and willing to do what is necessary to make things go better.

Benjamin Melançon (not verified):

Decentralized means so much to me from a practical, moral, political perspective that it alone sells me on Git.

Drupal already has many of the advantages of Git-style distributed development: don't hack core, use core, and give many a fool like myself commit access to their own module.

Linus mentioned people doing the hard work in Git and exporting back to Subversion; perhaps we could try to do some contributed modules this way with CVS, to bridge both worlds. (I've been meaning to ask the relevant summer of coders, but in case they check here first: are extensions to project / case tracker keeping multiple version control options in mind?)

Quite apart from what Drupal uses for source code management, I'm fascinated by a crazy idea: websites that themselves are (or can be) decentralized, distributed, and updated or synchronized according to networks of trust.

I think this is a natural evolution of content management, which is the evolution Drupal helps lead.

Benefits would be speed of working with data locally, built-in collaboration and revisions, relative indestructibility of content stored in multiple locations, and empowering people to become not just a content provider, but a content publisher also.

Drawbacks include that it's absolute fantasy.

For now.

Tj Holowaychuk (not verified):

I think the Drupal model is pretty solid, even though I hate CVS, but either way its still relatively simple, we are not creating very big projects, even Drupal its-self really is pretty small really. I am sold on Git after watching this, but I am not certain how relevant it could be to Drupal at least any time soon anyways