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