UPDATE:
Ignore everything below. A lot has changed since this blog post was written, and there are better / easier ways to sync up your schema.rb now than their were in 2009. And when in doubt, just run `rake db:schema:dump` when you get merge conflicts.
ORIGINAL:
The only argument for checking in schema.rb is that it's "faster."
Ignore everything below. A lot has changed since this blog post was written, and there are better / easier ways to sync up your schema.rb now than their were in 2009. And when in doubt, just run `rake db:schema:dump` when you get merge conflicts.
ORIGINAL:
The only argument for checking in schema.rb is that it's "faster."
Yeah, OK, whatever.
Don't check it into source control. It just leads to local development problems in the future, and possible production problems if you don't have CI, because cap deploy:migrations is going to run Rails migrations that might be broken because everyone primed the database using rake db:schema:load instead of rake db:migrations. Oh boy, does that sound like fun to you? Because it doesn't sound like fun to me.
Local development problems: consider Git, where everyone's got multiple branches. Someone's done some work in master, checked in their changed db/schema.rb. But oops, you've done some migration work too, and so now your db/schema.rb conflicts with the master db/schema.rb, and how do you end up resolving it? By nuking db/schema.rb and then running the new migrations to regenerate the file.
Which is an extra, unnecessary step because db/schema.rb is in source control.
Hurray.
Let's just keep db/schema.rb out of source control and save the 5 minutes.
