# Subversion and migrations confusion **URL:** \ **Category:** Rails\ **Created:** [July 15, 2006, 8:16pm UTC](https://www.ruby-forum.com/t/subversion-and-migrations-confusion/98539 "2006-07-15T20:16:51Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 15, 2006, 8:16pm UTC](https://www.ruby-forum.com/t/subversion-and-migrations-confusion/98539/1 "2006-07-15T20:16:51Z")
I’ve spent the last several months learning RoR and building my first app. I’ve not used migrations yet and honestly don’t understand them much, and have not had my app under version control. I’ve decided it’s time (I know, some will say way past time 😉 ) to put the app under version control. I’ll be using Subversion and have begun working through the “Pragmatic Version Control” book. It looks like I may need to move from using MySQL to postgreSQL and I understand one of the major benefits of using migrations is database independence. I’m confused about whether or not I should start using migrations so I can move to postgreSQL, then import into Subversion, then do I keep using migrations or are they are even necessary \ compatible when one is using Subversion, etc… I imagine you can see I’m back into an area of complete ignorance ;-( I’d really appreciate it if someone(s) could point me to whatever I should be reading / doing to understand how \ whether these two tools \ concepts work together. Thanks, Bill ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 15, 2006, 8:53pm UTC](https://www.ruby-forum.com/t/subversion-and-migrations-confusion/98539/2 "2006-07-15T20:53:24Z")
The cool thing about migrations is that they are, to the extent possible, database-independent. That makes the move from one database to another far less painful. Migrations are simply a way to incrementally build your database as your application evolves. Say, for example, your people table was working just fine but the client wants to add a column to track eye color (contrived example). You can simply create a migration using script/generate migration add\_eye\_color\_column to add the column, implement and test in your local app, then prop to production and run the same migration to add the same column on the production server. Version control is a totally separate issue, as it allows you to track your changes, work with others on a project, including their changes, and perhaps most important, roll back to a working version in the event you mess something up (like, nobody ever does that :). I find Subversion very good for Web App development and if you work through the Pragmatic book, using their examples, I think you’ll see why. As you might imagine, migrations are just more source code to be added to your Subversion repository. Should you need to roll back to an earlier snapshot, Subversion is smart enough to remove new migrations that don’t apply to that snapshot. For migrations, look at: [http://wiki.rubyonrails.com/rails/pages/UnderstandingMigrations](http://wiki.rubyonrails.com/rails/pages/UnderstandingMigrations) ## and for svn, you’re already on the right track. View this message in context: [http://www.nabble.com/Subversion-and-migrations-confusion-tf1948292.html#a5342867](http://www.nabble.com/Subversion-and-migrations-confusion-tf1948292.html#a5342867) Sent from the RubyOnRails Users forum at [Nabble.com](http://Nabble.com). ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 15, 2006, 9:06pm UTC](https://www.ruby-forum.com/t/subversion-and-migrations-confusion/98539/3 "2006-07-15T21:06:18Z")
Good point, but if a team agrees to a simple rule, this can be averted: Before creating a new model or migration, do an svn up ## Of course, this breaks the fundamental concept behind distributed development but we all have to live by some agreed-upon set of rules, right? I thing some clever use of precommit hooks might avert some of this by figuring out whether such a collision was imminent. Yes? View this message in context: [http://www.nabble.com/Subversion-and-migrations-confusion-tf1948292.html#a5342977](http://www.nabble.com/Subversion-and-migrations-confusion-tf1948292.html#a5342977) Sent from the RubyOnRails Users forum at [Nabble.com](http://Nabble.com). ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 15, 2006, 8:56pm UTC](https://www.ruby-forum.com/t/subversion-and-migrations-confusion/98539/4 "2006-07-15T20:56:44Z")
Hi – On Sat, 15 Jul 2006, s.ross wrote: > app, then prop to production and run the same migration to add the same > your Subversion repository. Should you need to roll back to an earlier > snapshot, Subversion is smart enough to remove new migrations that don’t > apply to that snapshot. Migrations and version control don’t play very well together when you have more than one person creating migrations for a given project, though, because the repository won’t complain if two people check in migrations with the same number. So you have to be careful to coordinate the order in which migrations are created, and how/when they’re saved to the repository. David – [http://www.rubypowerandlight.com](http://www.rubypowerandlight.com) =\> Ruby/Rails training & consultancy [Ruby for Rails](http://www.manning.com/black) =\> RUBY FOR RAILS (reviewed on Slashdot, 7/12/2006!) [http://dablog.rubypal.com](http://dablog.rubypal.com) =\> D[avid]A[.]B[lack’s][Web]log removed\_email\_address@domain.invalid =\> me ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 16, 2006, 3:08am UTC](https://www.ruby-forum.com/t/subversion-and-migrations-confusion/98539/5 "2006-07-16T03:08:01Z")
David, Phillip, Rob, S., Thanks much for your feedback. Alayed (sp?) a lot of fears. I appreciate it. Best regards, Bill ----- Original Message ----- From: Bill W. To: removed\_email\_address@domain.invalid Sent: Saturday, July 15, 2006 1:14 PM Subject: [Rails] Subversion and migrations confusion I’ve spent the last several months learning RoR and building my first app. I’ve not used migrations yet and honestly don’t understand them much, and have not had my app under version control. I’ve decided it’s time (I know, some will say way past time 😉 ) to put the app under version control. I’ll be using Subversion and have begun working through the “Pragmatic Version Control” book. It looks like I may need to move from using MySQL to postgreSQL and I understand one of the major benefits of using migrations is database independence. I’m confused about whether or not I should start using migrations so I can move to postgreSQL, then import into Subversion, then do I keep using migrations or are they are even necessary \ compatible when one is using Subversion, etc… I imagine you can see I’m back into an area of complete ignorance ;-( I’d really appreciate it if someone(s) could point me to whatever I should be reading / doing to understand how \ whether these two tools \ concepts work together. Thanks, Bill * * * * * * Rails mailing list removed\_email\_address@domain.invalid [http://lists.rubyonrails.org/mailman/listinfo/rails](http://lists.rubyonrails.org/mailman/listinfo/rails) ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 15, 2006, 9:34pm UTC](https://www.ruby-forum.com/t/subversion-and-migrations-confusion/98539/6 "2006-07-15T21:34:48Z")
On Jul 15, 2006, at 3:04 PM, s.ross wrote: > – > View this message in context: [http://www.nabble.com/Subversion-and-](http://www.nabble.com/Subversion-and-) > migrations-confusion-tf1948292.html#a5342977 > Sent from the RubyOnRails Users forum at [Nabble.com](http://Nabble.com). It seems like the good “team” thing to do might be: $ svn up $ script/generate migration fiddle\_with\_database --svn > > immediately add code to raise an exception when the migration runs class FiddleWithDatabase \< ActiveRecord::Migration def self.up raise IrreversibleMigration, “I’m working on it!” end def self.down IrreversibleMigration end end $ svn commit -m ‘preparing to fiddle\_with\_database’ That way, you’re reasonably protected from collision with the migration numbers and anyone who tries a migration can’t. (So you’d better have an understanding team if you can’t be done quickly.) -Rob P.S. I haven’t tried this, it’s just an idea since team\_for (:Rob).size == 1 Rob B. [http://agileconsultingllc.com](http://agileconsultingllc.com) removed\_email\_address@domain.invalid