On 02/05/2008, at 4:02 PM, Will Sargent wrote:
On Wed, Apr 30, 2008 at 12:27 PM, Alexey Verkhovsky
<[EMAIL PROTECTED]> wrote:
When people check in files, occasionally CruiseControl will error
out
saying that there's a conflict in schema.rb.
schema.rb is auto-generated on every build. If you have it checked
in, by
the time the build is over, you may have a locally changed
schema.rb and
when CC.rb tries to run an update, it may end up with a conflict.
The "Rails Way" is to have schema.rb in svn:ignore, and build your
database
from migrations.
That's what I thought as well.
Well different people have different takes on the issue, but I know a
bunch of the core team, as well as myself, use schema.rb as the
definitive DB definition. Migrations are simply a tool to help update
old versions of the database.
The "rails way", for what it counts, is to use schema.rb.
Then I saw this:
http://dev.rubyonrails.org/changeset/8124
44 # Note that this schema.rb definition is the authoritative
source
for your database schema. If you need
45 # to create the application database on another system, you
should be using db:schema:load, not running
46 # all the migrations from scratch. The latter is a flawed and
unsustainable approach (the more migrations
47 # you'll amass, the slower it'll run and the greater likelihood
for issues).
48 #
49 # It's strongly recommended to check this file into your version
control system.
So if you're SUPPOSED to check it into your version control system...
how do you manage it once it's there?
If you've created and run a migration you'll have both the migration
file and the new schema.rb to check-in. Nothing special about it, it
simply represents the schema the code code current code is written
against.
-- tim
_______________________________________________
Cruisecontrolrb-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
