ruby script/plugin install svn://svn.madriska.com/plugins/subverted_migrations

Create and use migrations as usual:
=============================

script/generate migration MyMigrationName

Example (with Chunky Bacon)
===========================
Assume you have trunk and a ChunkyBacon branch (/branches/chunky_bacon). Both have their latest migration at revision 010.

You create a migration in trunk:

  [trunk]$ script/generate migration BoringBacon
    exists  db/migrate
    create  db/migrate/011_boring_bacon.rb

Next, you want to create a migration in branches/chunky_bacon. Without this plugin, the new migration would have version number 011 and would create a merge conflict. With the plugin, the version numbers are kept in sync:

  [branches/chunky_bacon]$ script/generate migration ExtraCrispy
    exists  db/migrate
    create  db/migrate/012_extra_crispy.rb

The migration scripts should work as usual, but behind the scenes they keep track of which migrations have been run, 脿 la svnmerge.py. So let's say you run the migration from the branch:

  [branches/chunky_bacon]$ rake db:migrate
  Current version: 1-10
  Target version: 1-12
  == ExtraCrispy: migrating ==================================================
  (...)
  == ExtraCrispy: migrated (0.0000s) =========================================

  Final version: 1-10,12

This indicates that the migrated version contains migrations 1-10 (from before), as well as the ExtraCrispy revision (12). Once the Rake script detects that a file matching "db/migrate/011_*" has been added, it will apply that change as well. So if you merge the BoringBacon change from trunk into the Chunky Bacon branch, just run "rake db:migrate" and it will pick up the new change:

  [branches/chunky_bacon]$ (svnmerge...)
  [branches/chunky_bacon]$ rake db:migrate
  Current version: 1-10,12
  Target version: 1-12
  == BoringBacon: migrating ==================================================
  (...)
  == BoringBacon: migrated (0.0000s) =========================================

  Final version: 1-12

Note that version 11 has been incorporated, and now the version is 1-12.

You may also specify a version string on the command line. It can either be a series of ranges or numbers separated by commas ("1-6,7,12-42") or a single number, as before ("12", equivalent to "1-12"). To specify a single revision, you must express it as a range (to migrate to revision 6 only, specify "6-6").

To back out the BoringBacon change, we would specify the version string that removes version 11. The plugin includes a Rake task to show the current version:

  [branches/chunky_bacon]$ rake db:version
  1-12

We remove 11 from the range and give the new range as an environment variable:

  [branches/chunky_bacon]$ rake db:migrate VERSION="1-10,12"
  Current version: 1-12
  Target version: 1-10,12
  == BoringBacon: reverting ==================================================
  (...)
  == BoringBacon: reverted (0.0000s) =========================================

  Final version: 1-10,12

And now the change is backed out.

There is currently no advanced documentation for this plugin.