Prev | Current Page 455 | Next

Brad Ediger

"Advanced Rails"

Conversely, these migrations should be checked
in as soon as is practical after generation, so all developers have access.
Unfortunately, when using branches, it is not generally possible to publish every
schema change across all branches. If it were, a simple solution would be to set up a
shared migrations directory in the version control repository, and import it via a svn:
externals (or equivalent) declaration. In most cases, schema changes to separate
branches must be kept separate; at the least, production databases should not be polluted
with database changes for new features. So, another solution must be found.
There are several schools of thought on how this should work.
The simplest solution, which is probably the most popular, is Courtenay??™s Independent
Migrations plugin (http://blog.caboo.se/articles/2007/3/27/independent-migrations-plugin).
The basic assumption is that migrations which are created in different branches or
working copies are logically independent of each other. (If this assumption doesn??™t
hold, you will have problems when merging, no matter how you slice it.)
After installing the plugin, simply tag your independent migrations as such by inheriting
from ActiveRecord::IndependentMigration rather than ActiveRecord::Migration.
class AddFeature < ActiveRecord::IndependentMigration
# ...
end
Multiple independent migrations will then be applied concurrently, so migrations
can be merged without renumbering.


Pages:
443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467