Support for working in different branches in parallel

[jacobemcken]

Currently I'm in a situation where I've forked our master (git) and have been working on a new feature for a month. So far I have 44 changes to the database (ruckusing migrations), but in the same period of time master have "moved" ahead with about 20 of its own changes to the database.

So far I've rebased my fork on top of master and until now gotten all database changes in my development environment because of that. But when my feature is ready to go into production and I merge back into master there is no guarantee my migrations files will be applied in production.

Migration files - new feature (NF)
1 NF
2 NF
5 NF

Migration files - master
3 master
4 master - currently deployed in production

Migration files - master merged with NF
1 NF
2 NF
3 master
4 master - currently deployed in production
5 NF

In the above example when we update our production system migrations files 1 and 2 won't be applied because 3 and 4 is already applied. Do you have a recommendation for this scenario, if not I would like to request support for this (working in parallel on different branches which is merged back together).

Right now the only solution I can come up with is to rename all my 44 migration files to something that is newer than the current deployed version in production.

[salimane]

Hi,

I think apart from the potentially destructive

php ruckus.php db:migrate VERSION=1NF
php ruckus.php db:migrate

Some future commands could be :

php ruckus.php db:migrate redo VERSION=1NF,2NF,5NF

or

php ruckus.php db:migrate redo VERSION=1NF-2NF,5NF

If you want to have a go at those future commands, please do. If not I will put them on my to-do list

Thanks

[ruckus]

@jacobemcken - If I follow what you're saying then I believe there is an issue here. The tool SHOULD allow you to run all un-applied migrations, regardless of where the "max" applied migration is.

Well this would mimic the Rails/ActiveRecord migrations flow which was the impetus of this tool.

I think the flow should be: "run all migrations that I have not seen in order of their timestamps", regardless of what the actual timestamp is. Now, this might cause issues if another developer wrote a specific migration that conflicts with yours (lets say you both create the same table or something) but thats outside the scope of Ruckusing Migrations.

Let me dig into this.

[ruckus]

With latest master I am unable to replicate this.

My process:

1. Create 3 migrations spaced a few minutes apart. Don't run any of them (in fact the contents can be blank).
2. Take the highest migration number and insert it into the schema_migrations table manually to simulate that it has been executed.
3. When I run the db:migrate it does indeed show the first two pending migrations as candidates.

I think my process above represents your scenario but please let me know if I am missing something.

[ruckus]

Absolutely, its outside the scope of Ruckusing, hence my note about that in the issue update.

On Feb 1, 2013, at 11:39 AM, Jacob Emcken notifications@github.com wrote:

@ruckus About "the other developer" who wrote a migration that conflicts. In my opinion this should never be something Ruckusing should try to prevent. Because the issue could also be that two developers have created to classes in the code that conflict - same problem different layer :)

These issues should always be resolved by however is merging the two branches

—
Reply to this email directly or view it on GitHub.

[jacobemcken]

@ruckus I've played a little with it and I have no idea how I came to the conclusion that it didn't work.
It does... thanks for a great piece of software :)