7

I've been told that while developing I should source control everything under sites/ into my code repository (e.g SVN).

Assuming I'll never touch any of the contrib modules I use (ctools, views etc) but will only create my own theme, should I still do that?

Or should I just source control everything under sites/all/themes/?

thanks

2 Answers 2

10

In my team, we have moved to only sourcing what is specific to our current project. If we are using Views for example, we add the appropriate entry to our drush make-file, and version that, but not the module itself.

This leaves us with a very small repository, consisting of any custom modules specific to the current site, the current theme, and features exports.

Unless you absolutely can't use drush and drush make, I don't see why one should version control code that is well versioned somewhere else. And if you intend to hack on one of modules, then you should add that as a submodule, again, not versioning the code in your own repo. (I believe this is called a vendor branch in SVN).

Edit: For more details and a more advanced setup, you can take a look at this repository: git@github.com:letharion/Drupal-build-scripts.git The scripts are written in bash to support my teams workflow which includes a building a base-install profile (NodeStream), then our site-specific profile on top of that, a make file for each profile, hooks for applying patches or making other changes on individual build steps etc. I hope I will find the time to re-write it as a drush extension in the near future.

4
  • Thanks for your detailed explanation. Yes, I do use drush and plan to automate as much as possible. And I don't plan to change any code in core or contrib modules.
    – cherouvim
    Mar 23, 2012 at 11:33
  • +1 versioning the make file is a great idea, think I'll be doing that in future ;)
    – Clive
    Mar 23, 2012 at 11:47
  • 1
    @Letharion I don't quite understand how this works when developing the same site with various developers at the same time? AFAIK drush make always downloads all dependencies and tries to overwrite sites/default, even if those modules already have been D/L'd, or is there some undocumented option to only download updated/new modules? In other words: I understand the benefit of using Drush make for installing afresh, but how do you use it for keeping module dependencies synced in a distributed team?
    – Creynders
    Jul 3, 2012 at 8:51
  • I've been using this approach for over a year now but I'm now questioning whether it's really better than just having everything in a repo when working with other developers who may not be re-building the platform every day. Additionally, this approach is not really compatible with the way Acquia structures their repos for their cloud hosting. May 19, 2013 at 11:56
6

As a counter to @Letharion's answer, putting everything in SVN makes sense for some organizations and it really depends on how you do your rollouts. Putting contrib modules and themes in SVN can make sense if you ever need to go "back in time" and look at an old version of a site.

One example of this is handy when you suspect a bug in a contrib module, or are seeing different behavior. Being able to restore a full version from the past can help.

I have also found it handy to have a full site snapshot in SVN when I need to figure out what a client did to a site. I can take a full snapshot of their version, and stick it in SVN as a branch and compare.

3
  • In order to go "back in time" I'd also need the corresponding full database backup as well. Because some settings and configurations are in the DB. Is that right?
    – cherouvim
    Mar 23, 2012 at 13:34
  • Yes. The Backup and Migrate module and/or drush archive-backup is your friend here.
    – mpdonadio
    Mar 23, 2012 at 13:37
  • 1
    Using this method enables you to clone an entire installation from version control and a backup, which can be very helpful for development or debugging live sites.
    – keithm
    Mar 23, 2012 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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