you just have to choose, either schema.rb is god, in which case don't run migrations on cruise, or your migrations are god, in which case don't check in your schema.rb
it's that simple cc.rb depends on subversion, the problem here is that you can get subversion confused and then cc.rb is stuck On Fri, May 2, 2008 at 3:21 PM, Tim Lucas <[EMAIL PROTECTED]> wrote: > On 03/05/2008, at 3:20 AM, Jeremy Stell-Smith wrote: > > and don't forget, developers make mistakes...all the time. if they > > didn't there would be little point to a continuous integration system in the > > first place. what if I change a migration, then "forget to run it" before > > checking in. this is exactly what ci should protect you from, however, in > > your case instead of just failing, ci will go into an error state that the > > only way to fix is to log onto the box. > > > > no good. > > > > though it'd be nice for this *not* to happen. Surely there's a way around > it? > > I haven't used CC.rb in some time, but the way I used to have it set up is > that the production DB would be copied for CC.rb to test against, then > migrations were run, then the tests. If the DB was borked after one check-in > the next had a chance of fixing the migration as it'd rebuild the DB from > production and rerun the migrations. > > I don't like the idea of assuming your CC.rb schema is the same as > production simply because you're rebuilding from migrations each time. > > -- 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
