On 17/10/2007, Ivan Sergio Borgonovo mail@webthatworks.it wrote:
Modules in different sites tend to have different versions. Adding sites to the same code base may mitigate these problems.
I use the svn:externals property for that (developing modules branches outside the main Drupal core codebase). More write up here:
We have changed our repository a bit since then to make it a bit simpler, but you get the general idea and should be able to adapt it to your needs.
I can't see how it can be easily scriptable and version controllable. I see maintaining different code bases a management burden. I tweak something in a module (no matter how I would like to avoid to touch work maintained by someone else, but sometimes you've to do it). Then I've to replicate the same change everywhere or a) I'll forget b) changes in other modules won't be in sync.
It is trivial but it is one more management step.
That's why separating out your module development and using svn:externals (see link above) is so useful. You can check your module tweaks in once for a certain branch, and every site that uses that module branch automatically gets the updated module.
mmm let me understand... you share *all* the codebase including modules etc... with the exception of settings... just to edit the production settings before checkout and let it land on the server as you need it and not as on your local copy?
All settings live in the repo - we don't exclude anything from the repo.
No editing of production settings required. The production settings live in the repo under the production sites directory (eg /sites/example.com). Our deployment script does an svn export into a temp directory, then scps the files to the production server.