Setting up the ideal multiple repository Drupal Site version control with a DVCS

Question

I have an upcoming project that will use Drupal, and I've been toying around with repository setup ideas in my head for a bit now and while I've come up with a wishlist, I don't know how to actually set up a source control repository this way. While I'm using Drupal for this, hopefully this setup could be extensible to other CMS systems.

Ideally, I'd be using Mercurial/Kiln since that's what my shop uses, but I'd rather have an ideal workflow than use that particular too.

Here are the features I think are important

1. Drupal core should be a working copy from their repository, so that I can update it easily
2. Site specific configuration will be exported from the Drupal DB to files using Features/Strongarm, so the repository should have a sub repository that controls all of the configuration that is not part of Drupal Core
3. Part of this project might involve writing custom modules. These should also have a separate repository or sub-repository so that they can be managed without interfering with site-specific configuration
4. I'd like to avoid storing code from Drupal Core in my own VCS, since it's already managed by the initial checkout used for item 1.

Is there some combination of ignore settings, submodules/subrepositories, or other configurations that can yield a setup like this? If not, what are my best alternatives? Or perhaps am I approaching the problem wrong, and there is some well-known workflow that solves these kinds of problems?

Answer 1

A general workflow when it comes to Drupal is to clone the core repository and use it as the base for your local repository. Then, you'd create a separate branch specifically for your custom site, so as not to disturb the core branches.

Next, you'd add each module you'd want to use as a submodule off of this branch: this allows you to track specific versions of modules while still having the flexibility to easily upgrade them in the future.

Then, you'd set up an exclusion plan for user-generated content and your settings file. Generally, this would include:

• sites/SITENAME/files
• sites/SITENAME/settings.php

Finally, when you want to upgrade third-party content:

• With core, you'd pull the latest changes and rebase your custom branch
• With contrib, you'd navigate to the specific module's directory, pull the latest changes, and commit the new submodule hash to your custom branch.

The problem is, this works really, really well... if you use git. As Drupal has standardized on git, it's just a matter of linking to the correct drupal.org repositories and pulling when necessary.

If you're using a different VCS, submodules aren't really going to help unless you want to spend the time to convert each and every drupal.org repo for the modules you're using to whatever VCS you want to use. That's a lot of work, especially for a one-off project.

Alternatively, you could follow the above workflow, but instead of setting up a repo for each and every contrib module, you could set up one private repository called contrib, and manually add updates to contrib there. This way, you can keep contrib code separate, but you spare yourself having to maintain potentially dozens of custom repositories that do nothing other than duplicate drupal.org repositories.