Revision Control Systems

This group should probably have more organizers. See documentation on this recommendation.

This group provides one purpose:

Coordination about whether and how the code repository should be moved away from CVS to something else.

Note that as of fall 2007 this is largely a moot point - until is upgraded to Drupal6 there is no bandwidth among the infrastructure maintainers to handle this project. To move forward sooner would require surprising amounts of coordination and effort on a new contributor's part. Of course, discussion and work towards this end (via the revision control API module) will pay benefits now and down the road.

Before writing here, be sure that you are familiar withthe many posts by jpetso about revision control systems the new release system and our issue tracking system.

How to help at versioncontrol* modules


versioncontrol* modules is the family of modules that expose to drupal a way to interact with version control systems.

This is an incomplete list of the versioncontrol* modules, but these are the related ones with the git migration:

Please notice that versioncontrol module depends on other modules, so help at that modules would also help:

Read more
beckyjohnson's picture

How do I put an existing drupal site into git version control system.

I have begun reading documentation for git, because I need to start using a version control system for a site that I am working on. One thing that I haven't run into yet and which makes me nervous is, is there a way to put an existing drupal site into a git system, with a staging area and everything. I kind of understand how to start up a new repository and stuff, but not how to nudge a pre-existing site into one...


Read more
crea's picture

Aegir in Git-based deployment models

I currently deploy my changes from dev to production using Git. I find Git a priceless tool for managing my codebase and am seeking ways to automate my deployment tasks without writing too many shell scripts involving drush etc. Does anyone use Aegir as a tool to automate git-based deployment ? Please share your experiences

Read more
R-H's picture

Best practices for using Bazaar to version control your Drupal Install


I'm wondering how people use Bazaar to manage version control for their Drupal installations?

• Where do you bzr init? If you have root permissions would you put it at /
• What do you use bzr to version control for you? Do you add your whole www directory with Drupal?
• Do you store the branch local or publish it to Launchpad or another server?


Read more

Personal sandboxes/repos/branches for issues for git

We all agree that we want some sort of github-like fork/clone to participate in a project with git.
This means, that somehow, we want to be able that, for a given project and a given issue all users which have submitted a ssh key can contribute.

What we haven't decided on is how to do that, there are several ways.

One repository per project, per user

Each user gets a clone of the main repo hosted on d.o where she can do whatever she wants to.

Read more

pro-Mercurial points for shifting

Mercurial (or popularly, hg) is a DVCS written in Python. It is known for its ease of use, without compromising a lot of power.

See parent wiki page Action items for moving off of CVS for more generic information.



  • Mercurial has excellent Windows support and this was the major reason git was not Mozilla's choice for their DVCS.
  • Mercurial is just cool and can do the same.
  • Read more

    pro-Bazaar points for shifting

    Bazaar is DVCS written in Python, known for its very easy setup and good portability across all major operating systems.

    See parent wiki page Action items for moving off of CVS for more generic information.

    (start writing points already!)

    • Bazaar homepage:

    • Bazaar is the way to go if Drupal wants to lower barriers to contribution- Git has a steeper learning curve.

    • Bazaar might be an easier migration for cvs/svn users
    • Bazaar is easy.
    Read more

    pro-Git points for shifting

    Git is an advanced DVCS in C, that was initially written by Linus Torvalds. It is known for its amazing performance and superior flexibility.
    For details and starters, see

    See parent wiki page Action items for moving off of CVS for more generic information.

    Tools for the server

    Read more
    Mike_Waters's picture

    Using Git to manage both a core repo and project-specific repos

    I am currently using git to manage my site-specific projects, e.g. code that lives under /sites in a multisite (single core) scenario.

    However, I find myself needing to work on two things that will require a separate repository tracking the Drupal core: 1) one-off core patches, and 2) install profiles.

    Read more
    adrian's picture

    A critical look at the implementation of Plugin Manager - Underlying issues and possible solutions

    I have been harboring some growing concerns about the direction of the plugin manager integration proposals for Drupal core almost since their inception, but have not been able to make an informed opinion on the subject until I had properly reviewed the proposed system on a much deeper scale.

    While my impressions of the project and the current implementation are fairly negative, I have aimed to frame my criticisms in a positive constructive manner because I believe that the goals of the project are worthwhile, and that for a large section of users this could be a very flexible and usable solution.

    Unfortunately a lot of my concerns have been well founded, and I believe that the implementation of this system needs to be taken in a different direction for it to be able to succeed in its goals, while not negatively affecting projects like Aegir, Open Atrium and many other ‘serious developers’.

    Read more
    anarcat's picture

    Aegir code (and drush!) now accessible through git

    I have finally got around tackling git-cvsimport. After a little bit of tweaking around, I've been able to import the entire history of the various Aegir projects on in our git repositories. This will enable much easier collaboration and decentalised development.

    Read more
    haxney's picture

    Version Control API gathering #6 - June 21, 2009, on IRC

    A good talk this week, with a lot of stuff to say.

    • DamZ dropped by to discuss some of the issues and strategies surrounding the eventual migration of to the versioncontrol api. Maintaining the existing links could be a challenge, since they are dependent on the particular entries in cvs.module's cid field.
    Read more
    haxney's picture

    Issues to consider for multiple project branches

    One part of my GSoC is to add support (of some sort) to VersionControl API for having multiple branches within a project (like a project) with different user permissions. The idea is to allow a more DVCS-like workflow, where people can work independently on their own branch and then request an admin user to pull their changes into the master repository. I won't be starting this for a few weeks, but I wanted to get a discussion going about what it should look like.

    Read more
    jpetso's picture

    Version Control API gathering #5 - June 14, 2009, on IRC

    Whoa, seems I skipped one set of logs again. Anyways, here's what we discussed last Sunday. This time with even nicer formatting.
    Topics include:

    • Conceptual issues for dhax's Git hooks (→ using the 'update' hook for permission control so that branch pushes don't depend on other branches' validity)
    • The future of source items in the main API module (→ we want them as an optional bonus instead of a log-parse-time requirement)
    • Proper merging of commits from Git into CVS (→ git cvsexportcommit allows an "-m" option for prefixing a string to the commit message)
    Read more
    haxney's picture

    How to handle Git (or other VCS) allowed branch/tag names?

    I'm working on the Git hooks (specifically the 'update' hook right now) and am trying to figure out what sorts of things we would want in a pre-commit (or pre-push, in the case of DVCSs) hook.

    What I have now

    For now, I have only been checking whether the user attempting to push has an account with the given repository. Combined with the "admin must approve accounts" setting on repositories, this seems good enough to be useful.

    Read more
    jpetso's picture

    Version Control API gathering #3 - May 31, 2009, on IRC

    Ok, so gathering #2 was largely technical and a bit unfocused at times, I won't post that one because it probably won't make such a good read if you haven't been in #drupal-vcs in the first place. Today's gathering #3 seemed more interesting to me, and focused largely on workflow issues. The core outcome (imho) is that the students will post short daily "micro-blogging" updates so that mentors stay up to date on the status even if no progress is made for any reason. Using a dedicated d.o issue and/or Twitter respectively for these purposes. We also follow each other on Github now.

    If all goes well, the students should be pushing out their first weekly updates by tomorrow evening, which will also be tracked in a d.o issue (as discussed earlier). Complete log of today's IRC meeting follows below.

    Read more
    haxney's picture

    Refactoring common parts of xcvs-config.php, xsvn-config.php, etc.

    While perusing the xcvs code, I noticed that xcvs-config.php had a fair amount of code which was very non-cvs-specific, like xcvs_bootstrap and xcvs_get_temp_directory. These functions will be mostly or entirely identical for all backend hooks, so why not move them somewhere common, like in the versioncontrol module.

    It might make loading a bit more complicated, and it really isn't that much code (and seems fairly unlikely to change, so there won't be a big problem of keeping a lot of copied code in sync), so it probably isn't worth it if there is too much involved.

    Read more
    jpetso's picture

    Version Control API now mirrored on Github

    At least for the duration of SoC 2009, we're shifting upstream development of Version Control API to Github, with regular syncs from and to Drupal CVS. Feel free to fork one or more of the modules into your own branch, commit and push your own changes without upstream approval, and send merge pull requests when the feature is done.

    This move is being done because both of our SoC students as well as at the majority of mentors is fluent in Git, and the simultaneously developing branches is made a lot easier with a distributed version control system.

    Read more
    jpetso's picture

    Version Control API gathering #1 - May 17, 2009, on IRC

    Our first all-inclusive meetup, featuring both students (marvil07 and chrono325, now known as dhax) and two of three mentors (jpetso and sdboyer-laptop). Covered topics include development goals, workflow issues (using "gsoc2009" as well as "gsoc2009-marvil07" and "gsoc2009-chrono325" tags for issues), student development repositories (pushing everything onto Github for the time being), and how to manage further communication (there's going to be a weekly IRC meeting, every Sunday at 18:30 UTC). All subsequent logs will be tracked in the d.o issue

    Read more
    CorniI's picture

    Git and Drupal Core workflow

    This are just some random ideas about how we could organize drupal core development when/if it would be powered by git.
    Every (core) dev can request a personal git repo for drupal development. Here he can push his stuff too, in a special layout.
    The branches are named after issues the dev is assigned to. The base for them is the current HEAD (it's left to the dev pulling it in before starting his work!). Then the dev develops his patch. Whenever needed, he pulls the current HEAD in. When he's done with his patch, he uses a special tag name, and the magic starts:

    Read more
    Subscribe with RSS Syndicate content