What are the merits of using the various VCS (Version Control Systems) that exist to track Drupal projects?

Question

I'm trying to find the best version control strategy for my workflow with Drupal. I have multiple sites per install and I'm pretty sure I'll have a separate repository for each website. As far as I know, the VCSs worth considering are:

• SVN
• Bazaar (bzr)
• Git
• Mercurial (hg)

I know how these compare to each other in general, but want to learn their merits/demerits for Drupal. If you're using (or have used) any of these for Drupal:

• What is your setup?
• What about the VCS you chose works well for managing Drupal projects?
• What doesn't?

Answer 1

Our setup is based on Subversion. We have a smallish (less than 4) number of people who can make changes to the site, and we considered a DVCS like Git but concluded it was overkill.

We test our module with SimpleTest before committing any changes, and we make new tests if we've added a feature that isn't covered. In my opinion this step of testing before you commit a change is far more important than which version control program you decide to go with in the end.

Another important thing you should keep in mind when dealing with these programs is that you shouldn't just do a regular checkout to update the code on your production site. This will leave hidden .svn or other directories around which can contain passwords and other sensitive data.

Instead you should delete the module from your sites/all/modules directory and so an svn export to get a clean version of the latest code.

Version control is one part of the system for managing sites, be sure to also keep track of your site's configuration stored in the database, by backing up the database itself regularly (synched with svn commits would be ideal) and also by storing definitions of CCK content types externally to your main site if you can. You can import and export content types and Views so that they aren't stuck in your database if you need to rebuild your site's configuration.

The Deployment module is another thing to consider depending on your workflow.

Answer 2

Another subversion setup here.

Basic setup is:

• We track Drupal core and all contributed modules/themes we use each within their own folder in one part of our repository
  • Each of those has one subfolder 'drop', where new versions are copied into, once we start to use them.
  • Then we commit this as 'dropped version 6.x-y' - this leads to a local history of the release versions of Drupal core or the module in question (redundant to the 'official' cvs history at drupal.org, but more convenient to search/diff in case of problems)
  • Then we create a branch for the drop, named after the version (e.g. drupal-6.15, views-6.x-2.8) - this will normally be just used as is (see 'externals' below), but also serves as the baseline for custom changes to the module, if we need them. We try to avoid changes to core or contributed modules, but sometimes we need to fix a bug and can not wait untill the fix eventually ends up in an official release. So we make our changes and commit them on that branch. Once a new version comes in, we can diff it against our branch and eventually reapply the fix to the new versions branch, if it does not incorporate the fix already. This way, we have a complete and reusable overview of all core and module versions we use in different projects, including any customizations we eventually needed.
• For each of our Projects (sites), we create the usual SVN trunk/branches/tags hierarchy in a different part of the repository
  • We then use Subversions 'externals' definitions to pull in the core version, as well as all the additional modules we need from the branches described above. The important part here is that we can pull any version we need, so some sites might use a specially patched version of module x, while others might pull an unpatched previous version, and yet another uses the latest and greatest official release - we don't have to keep track of this mess, as SVN can tell us exactly what gets used when and where, at all times!
  • Then we add our project/site specific stuff - settings file(s), .htaccess files, project specific modules/themes, etc.
  • New development happens on trunk
  • Once we reach a release point, we create a release branch and tag that
  • We export that tag to the test/staging/live servers as needed
  • Meanwhile, new development can continue on trunk
  • Should we need to apply a fix to the current release version, this happens on the release branch
  • Again, the fix gets commited, tagged and finally exported and deployed
  • Should the fix be something needed in general, it gets merged back onto the trunk, so that it will be available in future versions in general
  • Lather, rinse, repeat ...

Pros:

• Mainly, a quite complete overview of all things that ever happened to any code within any of our projects :)
• Especially, the ability to track and reuse different versions of core or contributed modules within different projects, even with arbitrary custom changes, without creating an unmanageable mess (When, why and where did we use this custom one line fix within pathauto, and when, why and where did we stop using it - SVN logs will answer that)
• Reproducible deployments - should anything go wrong on a production server, we can export the exact set of code used there, with all one time fixes, adjustments and 'specialties' on the spot (obviously only useful in conjunction with proper database backups ;)

Cons:

• As easily to be seen from the descriptions above, this setup creates a bit of an administrative overhead when importing new core/module versions (and most of the time it even seems needless, as applying special fixes is a rare thing to do)
• Using externals definitions extensively like that makes update operations to the local checkout a bit more lengthy
• When a changeset implies a combination of changes to both, the project itself and a custom module imported via externals, it will not be an atomic commit, as they have to be checked in separately!

Conclusion:

As long as you have to manage only a handful of projects/sites, this might not be effective, and you might be better of committing and maintaining the whole setup (core, contrib and custom stuff) combined within one branch.

But I can assure that once you have to manage 10++ projects in parallel (some on 5.x, some on 6.x, all at different update and/or customization levels, often reusing the same customizations), being able to tell what code gets used where exactly is a huge relieve!

---

PS: Rereading my sermon, it is somewhat obvious that it does not really address your question regarding the merits of different VCS as compared to each other - sorry for that, but maybe it helps anyway ;)

Answer 3

Since I asked this question there has been a rather surprising development on the Drupal front: They have sort of maybe chosen a replacement for CVS! Citing massive community support, and the need for a distributed VCS, they will probably be moving to git.

I have previously considered and passed over git due to worse documentation and cross-platform support (compared to Bazaar and Mercurial), but since then they have improved massively in both areas and it seems it's now a really good option whatever your circumstances.

Therefore, if you are considering contributing to "core" or contrib modules, or writing your own module for the community, I would strongly recommend using git as it will have the most support and users in the Drupal community going forward. For that reason it's probably a good choice even if you're just tracking your own sites.

Answer 4

I would vote for git if you have many team members. While the Git documentation is still terrible - the free http://progit.org book and http://gitcasts.com make it easy to learn how to use. Since it is so independent it makes it easy to work on projects anywhere at anytime (vs SVN).

And I'm saying this as a guy with more SVN experience than git. Development is moving towards git and away from central systems like SVN.

Personally, the thing I like about it is how easy it is to jump back and forth through different test versions of your site (using branches).

Answer 5

Drupal doesn't have any specific requirement compared to any other general software source.

Here is Git/Mercurial vs. Subversion:

• Git (but also true for Mercurial)
  • Line endings would be normalized (no matter RL+LF or LF or... it would be stored as a 'line return' and unpacked as the OS format says)
  • A single file .gitignore allows to tell all files you'd like to ignore
  • You wont have a .svn folder in each of your folders (which forces to use the slow export function or a custom batch to remove them)
  • Extremely simple to setup locally
    1. Download Git and start the command line
    2. Go to your project folder
    3. git add . && git commit -m "My first commit"
    4. Done, you now can change files and revert to your first commit already
  • Good to share code in an OpenSource project via GitHub
  • Has TortoiseGit on Windows if you want a simple GUI (at the cost some advanced features), but it's a bit harder to install than TortoiseSVN
• Subversion (SVN)
  • Somewhat simpler to create your own private server
  • Has ToirtoiseSVN on Windows if you want a simple GUI (at the cost some advanced features)
  • Clear client/server: Meaning also you'll have to keep a server running (possibly on the same machine as the client) to use the client
• I cannot say much about Bazaar as I haven't used it

Clearly I'm biased toward Git and Mercurial. Both are more recent. I personally prefer Git because:

• It doesn't require Python
• There is portable version
• It allows me to rewrite history

Still you should note that Mercurial got Google's attention recently (for Google Code) and it's somewhat simpler to learn. You can learn Git from http://progit.org/book/ (the first 3 chapters should be enough).

As for the project folder structure, I suggest you look-up other answers. Keep in mind your goal (ex: testing, quick deployment on various machines...), and backup your repository. That means copying your project folder to a remote location for Git/Mercurial, and copying your Subversion server repository for Subversion. Outside of that, all have hooks allowing you to run tests before committing, and they have interfaces to bug tracking systems.

Least but not least, if you use other libraries under version control in your project, consider that! Git and Mercurial allow to track a Subversion repository (via git-svn), not the opposite. Mercurial can also track a Git repository, not the opposite (yet). Tracking a remote repository allows your to get the latest version with a change log of remote source code you'll be using. It also allows you to modify it.