Apply South migrations with already applied migrations

Question

In the master branch of our project, the migrations of one of our django apps looks like this:

# ...
(*) 0022_datamigration_1
(*) 0023_datamigration_2
(*) 0024_datamigration_3
(*) 0025_datamigration_4

As you can see, those migrations are already applied on our production system. In a branch of mine, I developed a feature which requires quite a lot migration:

(*) 0022_datamigration_1
( ) 0023_my_schemamigration_1
(*) 0023_datamigration_2
( ) 0024_my_datamigration_1
(*) 0024_datamigration_3
(*) 0025_datamigration_4
( ) 0025_my_datamigration_2
( ) 0026_my_schemamigration_2
# ... some more not yet applied schemamigrations
( ) 0030_my_datamigration_x

This is again the "migration history" of the production database, but because I worked simultaneously on my feature while the master changed, some of the migrations were already applied, and now I have these "gaps" in the history. South will deny appling them by running python manage.py migrate my_app

 ! Migration my_app:0024_datamigration_3 should not have been applied before my_app:0024_my_datamigration_1 but was.
 ! Migration my_app:0023_datamigration_2 should not have been applied before my_app:0023_my_schemamigration_1 but was.

How can I get rid of those "Migration gaps" (I guess I'm feeding Google with the wrong keywords)? At least, the migrations should all affect different models, so I guess it is possible to do it somehow.

Answer 1

First, you'll save yourself a ton of headache if you consolidate your migrations before committing new code. Let's say you generated schemamigrations numbered 0023, 0024, and 0025 in the course of development. Before committing anything you should rollback to the migration right before you started making changes (0022 in this case):

python manage.py migrate someapp 0022

Then, delete your three migrations, and finally generate a new schemamigration:

python manage.py schemamigration --auto someapp

Now, you have just one migration, 0023, with all the changes you made combined. This makes it much easier to merge your migration into the rest.

Then, when you do your merge, there might be a 0023 already, e.g.

0023_someone_elses_migration.py
0023_my_migration.py

Just rename the number on yours to one more than the maximum (if there's migrations now all the way up to 0030, you'd rename yours to 0031). Then, commit the merged code.

In general, though, good development practices should dictate that only one developer work on any piece of a codebase at any given time. It's not always possible, but in general, if you're working on some feature in "someapp", and a bug fix needs to be done on something else in "someapp", you should be the one doing it. Even if the change will be made in an entirely different branch, you'll be able to compensate by merging the change back into whatever else you're working on, whereas another developer would have no clue.