We are currently doing some development on a variety of branches that each have their own set of migrations (gee, database changes on a branch? how novel). The problem is with this strictly linear numbering of the migrations and these alternate branches. Let''s suppose I have branches/foo that adds two migrations 024_add_foo.rb and 025_refine_foo.rb and then another branches/bar that adds a single migration 024_add_bar.rb. First, it seems obvious that I need to duplicate the development database for each branch... Otherwise, I''m going to have version number clash... But then how do I manage merges etc. Is it enough to just manually renumber migrations when a merge takes place? Has anyone developed a well thought-out strategy here?
On 6/26/06, Lee Iverson <leei@ece.ubc.ca> wrote:> We are currently doing some development on a variety of branches that > each have their own set of migrations (gee, database changes on a > branch? how novel). The problem is with this strictly linear numbering > of the migrations and these alternate branches. > > Let''s suppose I have branches/foo that adds two migrations > 024_add_foo.rb and 025_refine_foo.rb > > and then another branches/bar that adds a single migration 024_add_bar.rb. > > First, it seems obvious that I need to duplicate the development > database for each branch... Otherwise, I''m going to have version number > clash... > > But then how do I manage merges etc. Is it enough to just manually > renumber migrations when a merge takes place? Has anyone developed a > well thought-out strategy here?I don''t have an answer for you, but I know that I''m going to be facing the same issue in a different context. We are looking at sharing a set of models across two different apps. I don''t see how migrations can work with shared models or different branches, w/o doing some hackery to adjust the version numbers to match when the migrate is done. - rob
On 6/26/06, Lee Iverson <leei@ece.ubc.ca> wrote:> We are currently doing some development on a variety of branches that > each have their own set of migrations (gee, database changes on a > branch? how novel). The problem is with this strictly linear numbering > of the migrations and these alternate branches.Does Rails fail to migrate if two migrations have the same number? At any rate, even if you manually sort out the numbers before the merge, Subversion will happily let you commit all of them to the same branch and not realize if you have migrations that conflict (i.e. the same table is modified in conflicting ways in two branches). I can''t think of any fool-proof method of resolving the two, besides merging the schema files and replacing the migrations with one giant up() that loads it all. Sincerely, Tom Lieber http://AllTom.com/ http://GadgetLife.org/
Regardless of some automatic means to merge migration files, you''re still going to have do some work since the changes to the actual DB that those migrations represent may conflict, i.e. branch_a/025_migration.rb might add ''table_foo'' with some schema, whereas branch_b/025_migration.rb might add the same table with a completely incompatible migration. Basically, you''re going to have to do some extra work when you merge back into a single working copy regardless. - james On 6/26/06, Tom Lieber <alltom@gmail.com> wrote:> On 6/26/06, Lee Iverson <leei@ece.ubc.ca> wrote: > > We are currently doing some development on a variety of branches that > > each have their own set of migrations (gee, database changes on a > > branch? how novel). The problem is with this strictly linear numbering > > of the migrations and these alternate branches. > > Does Rails fail to migrate if two migrations have the same number? > > At any rate, even if you manually sort out the numbers before the > merge, Subversion will happily let you commit all of them to the same > branch and not realize if you have migrations that conflict (i.e. the > same table is modified in conflicting ways in two branches). I can''t > think of any fool-proof method of resolving the two, besides merging > the schema files and replacing the migrations with one giant up() that > loads it all. > > Sincerely, > > Tom Lieber > http://AllTom.com/ > http://GadgetLife.org/ > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- * J * ~
On 6/27/06, James Adam <james.adam@gmail.com> wrote:> Regardless of some automatic means to merge migration files, you''re > still going to have do some work since the changes to the actual DB > that those migrations represent may conflict, i.e. > branch_a/025_migration.rb might add ''table_foo'' with some schema, > whereas branch_b/025_migration.rb might add the same table with a > completely incompatible migration. Basically, you''re going to have to > do some extra work when you merge back into a single working copy > regardless.Err, you quoted me, but seem just to repeat what I said. Did I miss something?> - james> On 6/26/06, Tom Lieber <alltom@gmail.com> wrote: > > At any rate, even if you manually sort out the numbers before the > > merge, Subversion will happily let you commit all of them to the same > > branch and not realize if you have migrations that conflict (i.e. the > > same table is modified in conflicting ways in two branches).Sincerely, Tom Lieber http://AllTom.com/ http://GadgetLife.org/