The plugin changes Rails's schema versioning to use version strings instead of integers, so you can have a version of "1-12,16-19" for example (with the missing versions being in another branch to be possibly merged in later). It also patches the db:migrate task to handle this versioning, as well as modifying the generate script to keep version numbers unique across all branches and trunk.
It is in alpha right now, but it is working well enough for me.
Is this something that would be a useful addition to Rails core? I'd appreciate some feedback / criticism.
> 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 version control problems is communication, not complicated naming schemes. Whenever I have a problem with migration numbers I just: migrate down, merge, migrate up, commit.
On Dec 4, 2006, at 11:05 AM, Manfred Stienstra wrote:
> On Dec 4, 2006, at 4:55, Brad Ediger wrote:
>> 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 > version control problems is communication, not complicated naming > schemes. Whenever I have a problem with migration numbers I just: > migrate down, merge, migrate up, commit.
Thanks for the feedback. I don't think it's terribly complicated once you get used to it. With this change, you shouldn't have to think about merges when writing migrations. I just created kind of a contrived example to show that everything Just Works. Perhaps the complicated example obscures understanding.
The reason I wrote the plugin is to keep from having to fudge the migration version numbers when merging. I think it's a messy solution to have to back out schema changes in order to keep your versions straight. That sounds like a programmer serving his tools, and it doesn't work if you have even one irreversible migration.
Is there a particular part of the documentation you think is complicated, or is it a specific part of the workflow that is confusing?
On 12/4/06, Brad Ediger <b...@bradediger.com> wrote:
> On Dec 4, 2006, at 11:05 AM, Manfred Stienstra wrote:
> > On Dec 4, 2006, at 4:55, Brad Ediger wrote:
> >> 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 > > version control problems is communication, not complicated naming > > schemes. Whenever I have a problem with migration numbers I just: > > migrate down, merge, migrate up, commit.
I agree, it does look complicated. I guess it depends on your workflow though. Usually, I work solo or in a small team, so there aren't a lot of branches. I haven't had any real issues with this as long as I keep in contact.
> On 12/4/06, Brad Ediger <b...@bradediger.com> wrote:
>> On Dec 4, 2006, at 11:05 AM, Manfred Stienstra wrote:
>>> On Dec 4, 2006, at 4:55, Brad Ediger wrote:
>>>> 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 >>> version control problems is communication, not complicated naming >>> schemes. Whenever I have a problem with migration numbers I just: >>> migrate down, merge, migrate up, commit.
> I agree, it does look complicated. I guess it depends on your > workflow though. Usually, I work solo or in a small team, so there > aren't a lot of branches. I haven't had any real issues with this as > long as I keep in contact.
I also work solo / in small teams, but I tend to have long-lived feature branches that don't get merged into production for a while (weeks to months) while developing and testing. These branches typically involve large schema changes that should be isolated from the production branch. Is there a more Rails-ish way to do schema branches like this?
> >>>> 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 changes.
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..
Courtenay wrote: > > >>>> 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 > changes.
> 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 is horrible.
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 again.
> Courtenay wrote: > > > >>>> 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 > > changes.
> > 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 > is horrible.
> 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 > again.
>>> 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 >>> changes.
>>> 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 >> is horrible.
>> 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 >> again.
I'm in the process of writing it. I don't have tests yet, but I can migrate up and down with no problem at this moment. I'll try and release my patch as a plugin, so it can be tried.
If I understand your suggestion correctly, it amounts to sorting and applying migrations based on timestamp. I think real time is not the right dimension for this as progress on different branches is not coordinated by time. Rather, I suggest to apply migrations in the order of their corresponding revision numbers. This approach doesn't guarantee that there can be no conflicts when branches are merged, but I think this can't be guaranteed anyway.
