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 :wink: ) 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

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.

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.

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 => 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
[email protected] => me

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: [email protected]
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 :wink: ) 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
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

On Jul 15, 2006, at 3:04 PM, s.ross wrote:


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 B. http://agileconsultingllc.com
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs