Rails best practice is to track db/schema.rb in version control, but Enki does not track it. Generally, version control best practices dictate that generated files are not tracked, and db/schema.rb is a generated file in some sense. But the default Rails .gitignore does not exclude it because: Migrations, mighty as they may be, are not the authoritative source for your database schema. That role falls to either db/schema.rb or an SQL file which Active Record generates... http://guides.rubyonrails.org/migrations.html#what-are-schema-files-for Remove db/schema.rb from .gitignore and add it to Git version control. This version of db/schema.rb was generated by running the current set of migrations (which also regenerates db/schema.rb).
* Remove self from up and down method * Use add_index helper to create index * Use symbol everywhere
… and post show.
…pplicable and modifying as needed. Also upgrade gems and plugins.
- Removed all vendored gems and added proper config.gem entries in the environment file - Refactored configurations to proper locations such as config/session_store.rb - Upgraded Rspec, Rspec Rails and Cucumber and fixed tests to make them pass - CommentsController is missing index.atom.builder - removed until properly implemented - Upgraded open_id_authentication plugin - Run rake gems:unpack if you want to vendorize the gems again
This is not supported by the openid plugin, and is kinda useless info anyway
…ber any existing tables
Without this, a clean clone doesn't migrate on VERSION=8. I'm not sure this is the proper solution, but it seems ok, especially since the next command sets all of these values equal to updated_at. I wonder if there's a better way to do this, but I don't understand migrations as well as I should.