This is interesting, and I''m still not exactly sure what''s causing it. When people check in files, occasionally CruiseControl will error out saying that there''s a conflict in schema.rb. I can go into cruisecontrol and svn revert the file, but it''s cropped up several times, and I''m getting a little tired of it. How does schema.rb work? I''ve read through The Rails Way and some online references, but I still don''t really think I understand how Rails, integration testing and database migration all interact. What''s the usual cause of this, and is there some series of steps in CruiseControl or rake that prevents this happening? Will.
schema.rb is a generated file. It''s constructed from your development database structure, and used to create the test database every time you run tests. Although I''ve seen people argue that you should leave it, in my version control world generated files are never checked in to the repository. You should: 1. delete it from your subversion repository 2. tell svn to ignore it After those two steps, your builds should run more smoothly. Regards, Lori On Wed, Apr 30, 2008 at 11:16 AM, Will Sargent <will.sargent at gmail.com> wrote:> This is interesting, and I''m still not exactly sure what''s causing it. > > When people check in files, occasionally CruiseControl will error out > saying that there''s a conflict in schema.rb. I can go into > cruisecontrol and svn revert the file, but it''s cropped up several > times, and I''m getting a little tired of it. > > How does schema.rb work? I''ve read through The Rails Way and some > online references, but I still don''t really think I understand how > Rails, integration testing and database migration all interact. > What''s the usual cause of this, and is there some series of steps in > CruiseControl or rake that prevents this happening? > > Will. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080430/d312c396/attachment.html>
Your best bet is to SVN ignore schema.rb. Rails generates it any time you do db:migrate so that when you do db:test:prepare, it will know what schema to make your test environment equal to. If you add a migration and migrate up to that point and commit your schema.rb file, and someone does SVN up but choses not to migrate yet, they are pretty much guaranteed to get conflicts. Billy On Apr 30, 2008, at 10:16 AM, Will Sargent wrote:> This is interesting, and I''m still not exactly sure what''s causing it. > > When people check in files, occasionally CruiseControl will error out > saying that there''s a conflict in schema.rb. I can go into > cruisecontrol and svn revert the file, but it''s cropped up several > times, and I''m getting a little tired of it. > > How does schema.rb work? I''ve read through The Rails Way and some > online references, but I still don''t really think I understand how > Rails, integration testing and database migration all interact. > What''s the usual cause of this, and is there some series of steps in > CruiseControl or rake that prevents this happening? > > Will. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean.-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Beat me to it! Drats. Here is a handy article I use any time I need to remember how to properly use SVN ignore. Hope it helps Will. http://wiki.rubyonrails.org/rails/pages/HowtoUseRailsWithSubversion Billy On Apr 30, 2008, at 10:35 AM, Lori Olson wrote:> schema.rb is a generated file. It''s constructed from your > development database structure, and used to create the test > database every time you run tests. Although I''ve seen people argue > that you should leave it, in my version control world generated > files are never checked in to the repository. > > You should: > > 1. delete it from your subversion repository > 2. tell svn to ignore it > > After those two steps, your builds should run more smoothly. > > Regards, Lori > > On Wed, Apr 30, 2008 at 11:16 AM, Will Sargent > <will.sargent at gmail.com> wrote: > This is interesting, and I''m still not exactly sure what''s causing it. > > When people check in files, occasionally CruiseControl will error out > saying that there''s a conflict in schema.rb. I can go into > cruisecontrol and svn revert the file, but it''s cropped up several > times, and I''m getting a little tired of it. > > How does schema.rb work? I''ve read through The Rails Way and some > online references, but I still don''t really think I understand how > Rails, integration testing and database migration all interact. > What''s the usual cause of this, and is there some series of steps in > CruiseControl or rake that prevents this happening? > > Will. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080430/e3ebfef3/attachment-0001.html>
> 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. -- Alex
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. 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? Will.
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
Jeremy Stell-Smith
2008-May-02 06:44 UTC
[Cruisecontrolrb-users] Conflicts with schema.rb?
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 <t.lucas at toolmantim.com> wrote:> 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 > > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080501/f471f7aa/attachment.html>
On Fri, May 2, 2008 at 12:17 AM, Tim Lucas <t.lucas at toolmantim.com> wrote:> The "rails way", for what it counts, is to use schema.rb.Oh well... then I guess it''s the ThoughtWorks Rails Way to not check in schema.rb (or any other files generated at build time)... it''s an opinionated continuous integration software. :) On a more serious note, if you insist on having schema.rb in the version control, you need to define a "cruise" Rake task such that it''s not regenerating that file during the CI build. Or tell CC.rb to always make a clean checkout. Otherwise local changes and merge conflicts will happen. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com]
On Thu, May 1, 2008 at 11:48 PM, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:> On Fri, May 2, 2008 at 12:17 AM, Tim Lucas <t.lucas at toolmantim.com> wrote: > > The "rails way", for what it counts, is to use schema.rb. > > Oh well... then I guess it''s the ThoughtWorks Rails Way to not check > in schema.rb (or any other files generated at build time)... it''s an > opinionated continuous integration software. :)I ignore schema.rb too, for better or worse :) Here''s something from my colleague that may be helpful, even though I haven''t really followed this thread :) http://pivots.pivotallabs.com/users/alex/blog/articles/305-collapsing-migrations -- Chad
Can someone explain why you would expect to see schema.rb conflicts if the checked in migrations are in sync with the checked in schema.rb? Wouldn''t you expect cruise to generate a schema.rb identical to the one checked in? On Fri, May 2, 2008 at 2:44 AM, Jeremy Stell-Smith < jeremystellsmith at gmail.com> wrote:> 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.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/73498069/attachment.html>
There shouldn''t be conflicts in that case. There is a case where you may use migration 20, and then someone in your team will use migration 21, so when you make a new migration you will use 22. If the dev who used migration 21 did not check their stuff in yet, so as far as your schema goes, you''re up to version 22 ... but you''re still missing migration 21 until that person checks it in. On May 2, 2008, at 9:48 AM, John D. Hume wrote:> Can someone explain why you would expect to see schema.rb conflicts > if the checked in migrations are in sync with the checked in > schema.rb? Wouldn''t you expect cruise to generate a schema.rb > identical to the one checked in? > > > On Fri, May 2, 2008 at 2:44 AM, Jeremy Stell-Smith > <jeremystellsmith at gmail.com> wrote: > 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. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/2a6ffaab/attachment.html>
-----cruisecontrolrb-users-bounces at rubyforge.org wrote: -----> Can someone explain why you would expect to see schema.rb conflicts if > the checked in migrations are in sync with the checked in schema.rb?Indeed, 99% of the time it would generate the same schema.rb, and therefore no conflicts will happen. But then someone manually creates an index in their local dev environment, and accidentally checks in the resulting schema.rb, without adding that index to migrations. Oops. -- Alex
Jeremy Stell-Smith
2008-May-02 17:20 UTC
[Cruisecontrolrb-users] Conflicts with schema.rb?
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. On Fri, May 2, 2008 at 9:57 AM, Billy Kimble <bkimble at inc21.com> wrote:> There shouldn''t be conflicts in that case. > There is a case where you may use migration 20, and then someone in your > team will use migration 21, so when you make a new migration you will use > 22. If the dev who used migration 21 did not check their stuff in yet, so as > far as your schema goes, you''re up to version 22 ... but you''re still > missing migration 21 until that person checks it in. > > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. On May 2, 2008, at 9:48 AM, John D. Hume wrote: > > Can someone explain why you would expect to see schema.rb conflicts if the > checked in migrations are in sync with the checked in schema.rb? Wouldn''t > you expect cruise to generate a schema.rb identical to the one checked in? > > > On Fri, May 2, 2008 at 2:44 AM, Jeremy Stell-Smith < > jeremystellsmith at gmail.com> wrote: > > > 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. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/c130cb45/attachment.html>
I guess we''ve never had this issue primarily because we rebuild the dev database from scratch on every build and always check in with a rake task does that before running specs and committing all modified files. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/d6833371/attachment.html>
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
Jeremy Stell-Smith
2008-May-02 22:38 UTC
[Cruisecontrolrb-users] Conflicts with schema.rb?
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 <t.lucas at toolmantim.com> 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 > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/79060afd/attachment.html>