3

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?

7

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.

  • Ok, so far I've cloned the drupal git repository, made a new branch (master) renamed the origin remote to upstream, run --set-upstream upstream/7.x (so I can pull from core correctly), then attached the master branch to a new repository on github. I'm left with three branches - 7.x, master, and upstream/7.x. Does this seem right so far? – Zxaos Aug 23 '11 at 4:30
  • 1
    @Zxaos that looks right: as a matter of style, I generally avoid master and use 7.x-dev and 7.x-prod, but same thing. Then, whenever you want to update your site to the latest core, you'd just rebase master from 7.x. – user7 Aug 23 '11 at 6:01
  • is there a specific style issue that arises from using master as a branch or is it just a personal preference thing? – Zxaos Aug 23 '11 at 13:47
  • 1
    @Zxaos everything in Drupal is dependent upon the core version, and at least in git, there is no branch that's "blessed" as the primary and mandatory branch like HEAD is in CVS. Avoiding master and using version-labeled branches makes it unambiguous what core version the branch corresponds to. – user7 Aug 23 '11 at 14:02
  • Everything here was working well - until I realized that when a new developer clones my repository, they lose the ability to pull updates from upstream since they don't get the 'remotes' configuration that's been set up. Any suggestions on how to make this workflow work for multiple developers? – Zxaos Oct 11 '11 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.