J-P<br><br>If you want developers to share code with the live site, then that<br>should work. <br><br>The database is not the only component here. There are modules<br>and themes too.<br><br>It is not a good idea to have developers share code that is actively 
<br>in development with a live site. You want to give them write access <br>to the sites/all/modules and sites/all/themes (and/or whereever else <br>they have code they need to muck around with).<br><br>This is not a good practice in general.
<br><br>Now, if you are talking testing/staging and live, where no code<br>changes are done, then you have a point.<br><br><div><span class="gmail_quote">On 8/16/07, <b class="gmail_sendername">J-P Stacey</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;">Tao Starbow wrote:<br>&gt; This is one of the cooler, not-so-well known drupal features.&nbsp;&nbsp;In
<br>&gt; settings.php you can define $db_url as an array<br>&gt; $db_url[&#39;default&#39;] = normal drupal string<br>&gt; $db_url[&#39;backoffice&#39;] = other mysql connect string<br>&gt;<br>&gt; then you use db_set_active( db_key ) to switch between them as needed.
<br><br>Is this a standard core feature, enabled by default? I feel like saying &quot;why<br>wasn&#39;t I told about this before?&quot; :)<br><br>One of the big problems we have is that many developers working on a given<br>
codebase: this means the codebase is in subversion and people check it out<br>to their own machines, work on it, check changes back in.<br><br>Some developers develop on the same machine, because their desktops are<br>WinXX and setting up LAMP stacks takes time. On this machine, whilst they
<br>can check out site-specific codebases to e.g.<br>sites/developername-<a href="http://clientname-devel.example.com">clientname-devel.example.com</a> and hence develop in their<br>own sandboxes, it&#39;s difficult to keep the site under revision and yet not
<br>have people be forced to share a database by settings.php .<br><br>But with the above a high-priority module could switch quickly and cleanly<br>between developers&#39; own sandboxed databases: does that sound right? How
<br>would you sneak in before any of the other modules? Would the following at<br>the end of settings.php be sufficient:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;db_set_active($_SERVER[&#39;HTTP_HOST&#39;]); // defaults to &#39;default&#39;<br><br>
Or is that too hacky? Can you even call a function from within settings.php<br>(notwithstanding the argument of &quot;would you want to?&quot;)<br><br>Somewhere among all this is functionality to make Drupal a good deal more
<br>&quot;enterprise&quot;, for whatever that hackneyed term is worth. Transparently<br>distributed development for large-scale, independent CMS teams on their<br>clients&#39; behalf.<br><br>Cheers,<br>J-P<br>--<br>J-P Stacey
<br>+44 (0)1608 811870<br><a href="http://torchbox.com">http://torchbox.com</a><br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://2bits.com">2bits.com</a><br><a href="http://2bits.com">http://2bits.com</a>
<br>Drupal development, customization and consulting.