self-reply here, pre-empting questions..
> >>>> Is this something that would be a useful addition to Rails core?
> >>>> I'd appreciate some feedback / criticism.
> >>> Wow, this looks really complicated. I think the solution with all
Why can't we just have a ParallelMigration (IndependentMigration)
subclass that doesn't check for duplicates in the numbering?
My most common use case is where I'm taking someone else's app,
checking it in locally with svk, adding some fields or models here and
there, but my changes are really in parallel with the original
In that case I'd have
We would assume from looking at the numbering that both 068_* are
somewhat dependent on 067, and come before 069. It would work only if
they are both this new independent migration class.
This opens up a whole new metaphor for thinking about migrations;
independent migration classes. So you'd add a few tables all at once,
but instead of putting then sequentially or in the same file, you make
3 parallel files.
I don't know if this solves the "long-running" branches issue, but
it's certainly simple..
I spend a lot of time doing branch-based development, where you make a
branch for each major feature. It's powerful, but merging migrations
What happens if you migrate up or down and you never applied one of the
parallel patches? or, if you merge someone's code and it contains old
migrations that you've progressed over?
For example, you're at version=52 but someone else's merged code adds
47 and 51, which you haven't run.. In this case you just migrate down
and up again..
What if you only applied one of the migrations 068, but you want to go
down anyway? I guess the IndependentMigration would have to specify if
you can skip it..otherwise, do what we all do when migrations half-run,
go in, comment out the offending code, migrate down, and uncomment it