Genius,<br>I&#39;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> &lt;<a href="mailto:jp.stacey@torchbox.com">jp.stacey@torchbox.com</a>&gt; 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>&gt; Perhaps something hacked into the projects/devel modules to switch
<br>&gt; the active DB on demand would be good?&nbsp;&nbsp;A developer could use his<br>&gt; own DB for development and then switch the DB to production for a<br>&gt; look and feel.<br><br>Yeah, this is a possibility. I&#39;ll have a look at those modules. We&#39;re
<br>already (as I explain below) using svn:ignore in our grand plan<br>(although slightly differently from Victor&#39;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&#39;s present. That way the database can be<br>safely wiped without losing that switch.<br><br>Steven:<br><br>&gt; If each developer has their own directory in the sites folder, don&#39;t<br>
&gt; they have their own settings.php? Aren&#39;t you just trying to move the<br>&gt; switching into one giant settings.php file?<br><br>Not quite: I didn&#39;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&#39;re still fleshing out goes as<br>follows.<br><br>We have a subversion repository containing &quot;core&quot; Drupal i.e.<br>everything bar the contents of sites/ . It&#39;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 &quot;core&quot; repository doesn&#39;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 &quot;core&quot; 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&#39;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&#39;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