On Thu, Jul 16, 2009 at 1:15 AM, Kathleen Murtagh
<kathleen@ceardach.com> wrote:
On Wed, Jul 15, 2009 at 5:54 PM, Bevan Rudge
<bevan@civicactions.com> wrote:
At CivicActions we have a tool (pushdb --xFix) that fixes the paths in
the files directory and elsewhere in the db, which we run when copying
an instance of the site to a staging environment. However this
approach is becoming unsustainable and we are considering using a
separate instances of Drupal core in each and every staging
environment so that they all use sites/default.
What this means is that much of the time this featurebug is such a
PITA that Drupal's multisite features don't work for staging
environments. In my own sandbox I don't use multisite for staging
environments at all, because of this issue, Do others?
I don't use multisite for managing dev, staging and production environments. In my workflow, it would be *more* complicated to use this method. I put the entirety of Drupal core into version control and deploy working spaces straight from version control. This makes it much easier to control exactly what and when code is pushed to production, and enable the ability navigate through the history to find sources of bugs.
The only time I use multisite is for actual separate, yet integrated websites. The most common use for me are multiple websites that share tables, like the user-related tables.