Django South migration conflict while working in a team

Question

I have a short question about how to use Django-South while working in a team.

What happens if two people simultaneously create migration file on changes to the same file?

For example, A and B are working on same Django app. They are working in different branch and both at migration 005. Now, both A and B modifies apple/models.py and created migration file using startmigration. They are both at migration 006 but with completely different migration file 006. I guess when they merge their branches, there might be some error with South.

Is there any workaround to resolve this conflict? Or is South smart enough to resolve it by itself?

Answer 1

South's documentation talks about this issue:

The issue with teams and migrations occurs when more than one person makes a migration in the same timeslot, and they both get committed without the other having been applied. This is analogous to two people editing the same file in a VCS at the same time, and like a VCS, South has ways of resolving the problem.

If this happens, the first thing to note is that South will detect the problem, and issue a message like this:

Inconsistent migration history
The following options are available:
    --merge: will just attempt the migration ignoring any potential dependency
        conflicts.

If you re-run migrate with --merge, South will simply apply the migrations that were missing out-of-order. This usually works, as teams are working on separate models; if it doesn’t, you’ll need to look at the actual migration changes and resolve them manually, as it’s likely they’ll conflict.

The second thing to note is that, when you pull in someone else’s model changes complete with their own migration, you’ll need to make a new empty migration that has the changes from both branches of development frozen in (if you’ve used mercurial, this is equivalent to a merge commit). To do so, simply run:

./manage.py schemamigration --empty appname merge_models

(Note that merge_models is just a migration name; change it for whatever you like)

The important message here is that South is no substitute for team coordination - in fact, most of the features are there purely to warn you that you haven’t coordinated, and the simple merging on offer is only there for the easy cases. Make sure your team know who is working on what, so they don’t write migrations that affect the same parts of the DB at the same time.