Genius, I'd never thought about using SVN and drupal in that way. Indeed some database switching would be awesome. might have to have a closer look at all this. Let me know if you get anywhere yourself! On 17/08/07, jp.stacey@torchbox.com <jp.stacey@torchbox.com> wrote:
Earnie:
Perhaps something hacked into the projects/devel modules to switch the active DB on demand would be good? A developer could use his own DB for development and then switch the DB to production for a look and feel.
Yeah, this is a possibility. I'll have a look at those modules. We're already (as I explain below) using svn:ignore in our grand plan (although slightly differently from Victor's suggestion), so one possibility is for a developer to put a file on disk containing the name of his preferred DB, set an svn:ignore on the parent directory and switch database if that's present. That way the database can be safely wiped without losing that switch.
Steven:
If each developer has their own directory in the sites folder, don't they have their own settings.php? Aren't you just trying to move the switching into one giant settings.php file?
Not quite: I didn't quite explain our plans for world domination fully! We still only have a small number of client sites in Drupal (3, well, 2.5 right now), but the plan we're still fleshing out goes as follows.
We have a subversion repository containing "core" Drupal i.e. everything bar the contents of sites/ . It's actually not just core: there are tags for Drupal 5.1 and 5.2, and also tags for both of these with our always-used modules (CCK, image etc.) Maintaining this separate from Drupal CVS gives us control if we really, really want to do something different from standard out-of-the-box Drupal. The sites/ directory has an svn:ignore on it, so we can dump whatever we want under there and the "core" repository doesn't notice.
Each client site has its own *separate* subversion repository, and this has its own settings.php file. This means that we can have e.g. three production servers, each with a single Drupal "core" instance, but then have e.g. ten client sites which we can roll out to any of those production servers and handle load, traffic spikes etc. If we know Client X is going to have a busy day, we can do DNS magic and redeploy the sites so that Client X is on a server on its own, and the other two servers share nine sites between them. Sites are completely plugin-able yet under subversion.
In this situation, although each *site* has a settings.php, each developer is checking out the same settings.php from the repository per site. They don't want to be editing settings.php in case it gets folded back into the repository, deployed to live and breaks it. This means that, if two developers are working on the same development server rather than on their desktops, then even if they work on different physical files on the filesystem, subversion still gives them identical settings.php, and without extra effort they will end up sharing a database.
Having some code that would switch database based on HTTP Host is ideal, really, as that's the main marker for Drupal to tell it which site it has to pretend to be ;) This switching seems perfectly natural, coming from an environment where local/live config switching is expected, and devel/test/prod config switching is generally desirable.
Cheers, J-P
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-- Regards Steven Jones