Experimental project

This is a sandbox project, which contains experimental code for developer use only.

A Drush command that utilizes the power of "drush make" to update modules and apply patches via a drush make file.

Managing your Drupal code base just got better.

Better how you say? What if I told you all patches were accounted for and apply 100% of the time? How about no extraneous files left over from an upgrade or knowing which version specific revision you are running even when you are using dev? Does Drush Make Sync do this for you? Nope! However, it forces you and everyone else on your team too, allowing for easier upgrades and constant accountability of your code base.

Now doesn't that want to make you say "Gee thanks Drush Make Sync". It does for me and and it can for you too, for the low, low price...meh. Just follow the instructions below.

Installing Make Sync


Drush version Working Untested Not supported Notes
< 5.8     not supported  
5.8 working*     * With patch to allow for local patch files.
5.9 working*     * With patch to allow for local patch files.
6.x working     #2135477: Works with Drush 6.1
7.x   untested    


Download the Drush Make Sync extension to your ~/.drush directory.

Clear the drush command cache: drush cc drush

You'll also need to apply a patch to your Drush installation to make it understand local patch files. Currently, that patch is http://drupal.org/node/840540#comment-6510712.

Creating a make file

Make sync uses regular drush make files.

When using a dev version of a module be sure to figure out which commit revision you are actually using and add the dev module as a git checkout.

projects[field_reference_delete][subdir] = "sandbox"
projects[field_reference_delete][type] = "module"
projects[field_reference_delete][download][type] = "git"
projects[field_reference_delete][download][url] = "git://drupalcode.org/sandbox/drothstein/1775816.git"
projects[field_reference_delete][download][revision] = "adb0a3c59cab26acc38523bf8e418c8c466063a9"

This ensures that we can verify the build correctly all of the time. If a dev package was specified and the maintainers of that project made a few changes and the dev package was rebuilt then your verification WILL fail because the devs are not the same.


Make files work the same as regular drush make files, with one exception: there's a list of excluded files that make sync will completely ignore. This is for things like custom modules and themes that won't be pulled down from Drupal.org, workspace directories (for instance, I keep my apache logs for each virtualhost inside the document root of each virtualhost, so the logs directory should be excluded), etc. If you already have file or directories excluded via the gitignore file then you do not have to add them to the make file. Drush Make Sync will automatically exclude any files from gitignore in the destination directory.

; Excludes (Custom modules, themes, libraries)
excludes[] = "sites/all/drush"
excludes[] = "sites/all/modules/custom"
excludes[] = "sites/all/modules/features"
excludes[] = "sites/all/themes/custom"
excludes[] = "sites/*.dev"
excludes[] = "sites/*.com"
excludes[] = "logs"

You may also add excludes via the command line via the --exclude="<pattern>,<pattern>" option.


Patches are automatically detected.


projects[media][subdir] = "contrib"
projects[media][version] = 2.0-unstable7
projects[media][type] = "module"
projects[media][patch][] = "sites/all/hacks/contrib/media/1830448-3-media-add_allowable_formats_per_type_in_media_browser_for_wysiwyg.patch"

projects[ctools][version] = 1.3
projects[ctools][type] = "module"
projects[ctools][subdir] = "contrib"
projects[ctools][patch][] = "https://drupal.org/files/ctools-current-page-query-token-not-returned-1964434-7.patch"

Using Make Sync

Using the make sync tool is a two step process: verify, and then sync.


Basically, the verification step builds a copy of your codebase in a separate directory as specified in the make file. It then compares the build directory and the destination directory. If the build directory and the destination directory are different, the tool will let you know and prompt you to fix the makefile before continuing. You can run verification like this:

drush make-sync site.make /tmp/site_build /var/www/site

Note: this CAN be can from within the destination directory. In this case, site.make is located at /var/www/site/site.make.

Also, if you know that the build does not require a new build and you just need a verify to do a sync you may run the command with the --verify flag. This will cause make-sync to only verify the build verses actually re-building the project.

drush make-sync site.make /tmp/site_build /var/www/site --verify


Once the makefile verifies properly, you can make a change in the makefile, run verification, then sync over the changes. For instance, a block in your makefile might look like this:

projects[views][subdir] = "contrib"
projects[views][version] = 3.4
projects[views][type] = "module"

You can bump the version to 3.5, then you can run the exact same command with --sync appended:

drush make-sync site.make /tmp/site_build /var/www/site --sync

This will copy any changed files in the build directory to the destination directory. Then, you can commit the files as normal.

I also recommend installing modules this way as well. So just as you would update a module after you verify you would add a new module to the make file and run sync.


On occasion the build will fail and you will need to allow make & make-sync to cleanup after itself. To do this run the same exact command as you would for verify, but with the --clean flag. This will clear our drush makes temp and the build directory.

drush make-sync site.make /tmp/site_build /var/www/site --clean


You may also optionally specify excludes via a command line option as a comma separated list --exclude="<pattern>,<pattern>". This will append to the automatically generated excludes list from .gitignore and the make file.

drush make-sync site.make /tmp/site_build /var/www/site --exclude="sites/all/temporary_module,cache*"


This project was sponsored by Advomatic and Mediacurrent.

Project information