it's still a generated file, and will still introduce conflicts on a system
like cruise if you're running migrations on said system - because each time
you do, it will regenerate a new copy of the file.
I suppose you have a choice, you could
a) don't check in schema.rb - let ccrb do it's default thing, which is to
run migrations before each build
b) check in schema.rb - don't run all migrations on your cruise box,
instead, generate the test db directly from schema.rb each build
I'll leave the rake tasks you'll need to call for option b to you. But,
when you have them, add this line to your cruise_config.rb file (either on
the server or in your project root)
project.rake_task = 'my_brand_new_cruise_rake_task'
or
project.build_command = 'rake db:... default'
that should do it.
Jeremy
PS. Good luck on finding the one true Rails Way that is clearly superior to
all other Rails Ways.
On Thu, May 1, 2008 at 11:17 PM, Tim Lucas <[EMAIL PROTECTED]> wrote:
> 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
>
_______________________________________________
Cruisecontrolrb-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
