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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060715/bed2a3cd/attachment.html
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 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 Sent from the RubyOnRails Users forum at Nabble.com.
Hi -- On Sat, 15 Jul 2006, s.ross wrote:> > 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.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 => Ruby/Rails training & consultancy http://www.manning.com/black => RUBY FOR RAILS (reviewed on Slashdot, 7/12/2006!) http://dablog.rubypal.com => D[avid ]A[. ]B[lack''s][ Web]log dblack@wobblini.net => me
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 Sent from the RubyOnRails Users forum at Nabble.com.
dblack@wobblini.net wrote:
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.
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.
I remember there was some discussion about this a while back.
Anybody out there tried fixing the problem with a subversion pre-commit hook
that rejects migrations with the same number?
Figured I''d see if anybody has done this before I write it up. It
would be great to see this issue go away.
phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060715/15d0cfea/attachment.html
On Jul 15, 2006, at 3:04 PM, s.ross wrote:> 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 > Sent from the RubyOnRails Users forum at 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 Biedenharn http://agileconsultingllc.com Rob@AgileConsultingLLC.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060715/ef1ef1e4/smime.bin
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 Walton To: rails@lists.rubyonrails.org 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 Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060716/8eb54e3f/attachment.html