What we do with distributed development is to make an svs:ignore on the settings file, while putting a mysqldump synched with revisions. With scripts, so that one does a checkout, runs a script and is all set to go on the local installation. What you are saying would certainly be more elegant, so if you make progress, please comment! saludos, Victor Kane http://awebfactory.com.ar On 8/16/07, J-P Stacey <jp.stacey@torchbox.com> wrote:
One of the big problems we have is that many developers working on a given codebase: this means the codebase is in subversion and people check it out to their own machines, work on it, check changes back in.
Some developers develop on the same machine, because their desktops are WinXX and setting up LAMP stacks takes time. On this machine, whilst they can check out site-specific codebases to e.g. sites/developername-clientname-devel.example.com and hence develop in their own sandboxes, it's difficult to keep the site under revision and yet not have people be forced to share a database by settings.php .
But with the above a high-priority module could switch quickly and cleanly between developers' own sandboxed databases: does that sound right? How would you sneak in before any of the other modules? Would the following at the end of settings.php be sufficient:
db_set_active($_SERVER['HTTP_HOST']); // defaults to 'default'
Or is that too hacky? Can you even call a function from within settings.php (notwithstanding the argument of "would you want to?")
Somewhere among all this is functionality to make Drupal a good deal more "enterprise", for whatever that hackneyed term is worth. Transparently distributed development for large-scale, independent CMS teams on their clients' behalf.
Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com