# Migrations and svn branches **URL:** \ **Category:** Rails\ **Created:** [June 26, 2006, 7:45pm UTC](https://www.ruby-forum.com/t/migrations-and-svn-branches/96139 "2006-06-26T19:45:28Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![leei](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/5fc32e/32.png) [@leei](https://www.ruby-forum.com/u/leei)\ **Post date:** [June 26, 2006, 7:45pm UTC](https://www.ruby-forum.com/t/migrations-and-svn-branches/96139/1 "2006-06-26T19:45:28Z")
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? ---
**Author:** ![leei](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/5fc32e/32.png) [@leei](https://www.ruby-forum.com/u/leei)\ **Post date:** [June 26, 2006, 7:53pm UTC](https://www.ruby-forum.com/t/migrations-and-svn-branches/96139/2 "2006-06-26T19:53:55Z")
On 6/26/06, Lee I. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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 ---
**Author:** ![leei](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/5fc32e/32.png) [@leei](https://www.ruby-forum.com/u/leei)\ **Post date:** [June 26, 2006, 10:53pm UTC](https://www.ruby-forum.com/t/migrations-and-svn-branches/96139/3 "2006-06-26T22:53:22Z")
On 6/26/06, Lee I. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 L. [http://AllTom.com/](http://AllTom.com/) [http://GadgetLife.org/](http://GadgetLife.org/) ---
**Author:** ![leei](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/5fc32e/32.png) [@leei](https://www.ruby-forum.com/u/leei)\ **Post date:** [June 27, 2006, 6:21pm UTC](https://www.ruby-forum.com/t/migrations-and-svn-branches/96139/4 "2006-06-27T18:21:44Z")
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 ---
**Author:** ![leei](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/5fc32e/32.png) [@leei](https://www.ruby-forum.com/u/leei)\ **Post date:** [June 27, 2006, 9:38pm UTC](https://www.ruby-forum.com/t/migrations-and-svn-branches/96139/5 "2006-06-27T21:38:11Z")
On 6/27/06, James A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 L. [http://AllTom.com/](http://AllTom.com/) [http://GadgetLife.org/](http://GadgetLife.org/)