Since Rails migrations are numbered sequentially in the order in which they
are generated (with respect to the current project), the generate script will happily
use a number that may have been in use elsewhere, in other versions of the project.
This causes difficulty upon merging. The typical workflow is this:
1. The current migration version number in the trunk is 123. You branch the
project for a new feature, and in the branch you generate a migration for the
database support:
[branches/feature]$ script/generate migration AddNewFeature
exists db/migrate
create db/migrate/124_add_new_feature.rb
2. You need to fix an issue in the trunk, so you create and apply a migration to
trunk. It is created with version number 124, because the other version 124 is
not visible yet:
[trunk]$ script/generate migration BugFix
exists db/migrate
create db/migrate/124_bug_fix.rb
3. Upon merging, there are two migrations with version 124. These must be manually
renumbered, which can be difficult if there were many migrations. The database
must then be migrated down to the lowest migration common to both
branches, and migrated back up. If the migrations are not fully reversible, the
changes may have to be applied manually.
This situation can also happen when there are multiple developers generating their
own migrations. The solution for that situation is good communication: developers
Version Control | 307
should always pull the db/migrate directory from the version control system immediately
before generating a migration.
Pages:
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466