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?
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.
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.
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.
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?
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).