On Wed, Sep 9, 2009 at 5:03 AM, Chris <c...@hapgoods.com> wrote: > > I see sublime elegance in having the DB store the DDL to revert > migrations. I haven't worked with large teams in years, but I see the > dilemma Steven is addressing: > > The common DB is at Rev N > User (or branch) A migrates common DB up to Rev N + 1 > User (or branch) B is "checked out" and expects common DB to be at Rev > N. > Result: User/branch B is stuck: code to rollback the DB to Rev N > exists only in User/branch A.
In this case, I would say that user (or branch) B should not be running outdated code against the 'common' database at Rev N +1. The +1 migration probably had some associated code changes to support the schema changes, and if user/branch B does not have that code yet, they shouldn't be running against that database. Either use a separate database, or cherry-pick the migration and associated changes from branch A. I think the concept of a "common" DB is the root problem here. Each developer should have their own DB in development, and in demo/staging/production, you should only be running a single branch (preferably a tag of a green CI build) against the DB at any given time. -- Chad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
