On Fri, Sep 9, 2011 at 6:42 PM, Jeff Hartman <[email protected]> wrote:
> On Sep 9, 2011, at 8:10 PM, Joshua Stoutenburg wrote: > > >> On Fri, Sep 9, 2011 at 3:49 PM, Jeff Hartman <[email protected]> > wrote: > >> I thought this would be straight forward, but alas I am confused. > >> > >> I typically have my database on my local machine, but I'm in a situation > where I need to move my database to a remote server so multiple people can > be developing at the same time. Drupal install and files are all local to > each developer. > >> > >> > > I've tried doing this before, not with Drupal, but with OpenCart. It > worked! But the time we lost to waiting for database queries in the end > wasn't worth it. > > > > Instead, anytime we made changes to the database in any way, we would > place a dated sql script in the repository to run against each local > database. Everyone was subscribed to repository notifications, so they knew > when an sql script was committed. > > I got it working. MySQL on the remote server was using old_password > authentication. Updating that fixed it, but you're right, it is horribly > slow. Horrible. > > Being that Drupal is basically built around the database (content types, > views, etc.), it is constantly in flux. I'm curious to hear what methods > people use for teams of developers working together and keeping everything > synchronized. > > Jeff > > > > That is a challenge I would like a solution to as well. So far, we've been just exporting dated sql scripts and committing them under a designated directory in the subversion repository (planning on switching to Git). I wish there was a solution similar to version control that would keep a list of all transactions and allow you to commit or ignore them. I think TOAD might have something like this but I haven't taken the time to figure it out.
