django and south migration with conflicts (0007_two ... and 0007_one) how to solve?

10
votes

I want to use south in my django project as migration tool, but I have problem with using south in multiuser scenario:

Two devs working concurrently on different machines create two migrations with same number

  • on first PC: 0007_extend_lizard.py

  • on second PC: 0007_swap_name_adopter.py

In this case I can run ./manage migrate --merge or ./manage migrate 0006 (rollback) and run again ./manage migrate. BUT when I want add new field in models.py and run ./manage startmigration southdemo --auto, then south gets models = {} meta data from the last migration, and it has have missing info from the first migration. The result of this is creating migration 0008 with creating again (!!!) changes from first 0007.

What's the best way to solve this problem?

Currently I'm thinking about two options:

  • Manually merge both 0007 migration in one file and then migrate (but some one must execute "rollback")

  • Manually move missing models = {} meta to last 0007 migration and then the next --auto in 0008 will work perfectly.

What is the better option? Or is there something else I'm missing?

1
djangomigrationdjango-south

1 Answers

16
votes

After doing the migrate --merge or rollback-and-migrate, if you know that the most recent migration now has inaccurate frozen models, I would just create a new no-op migration for the purposes of bringing the frozen models up to date. Just run ./manage.py startmigration myapp --empty freeze_noop. Now your frozen models will be up-to-date for the next time you want to autodetect a real migration.

Maybe it seems a little ugly to create a no-op migration, but to me this seems cleaner than either of the manual history-editing options you suggested. You can think of the no-op migration as the equivalent of a "merge commit" in a DVCS.

This issue ought to be mentioned in this section of the South docs; I've filed an issue for it. (Update: now it is.)