[Cruisecontrolrb-users] Conflicts with schema.rb?

[Tim Lucas]

On 02/05/2008, at 4:02 PM, Will Sargent wrote:

> On Wed, Apr 30, 2008 at 12:27 PM, Alexey Verkhovsky
> <averkhov at thoughtworks.com> 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