Maintaining South migrations on Django forks

Question

I'm working on a pretty complex Django project (50+ models) with some complicated logic (lots of different workflows, views, signals, APIs, background tasks etc.). Let's call this project-base. Currently using Django 1.6 + South migrations and quite a few other 3rd party apps.

Now, one of the requirements is to create a fork of this project that will add some fields/models here and there and some extra logic on top of that. Let's call this project-fork. Most of the extra work will be on top of the existing models, but there will also be a few new ones.

As project-base continues to be developed, we want these features to also get into project-fork (much like a rebase/merge in git-land). The extra changes in project-fork will not be merged back into project-base.

What could be the best possible way to accomplish this? Here are some of my ideas:

1. Use South merges in project-fork to keep it up-to-date with latest changes from project-base, as explained here. Use signals and any other means necessarry to keep the new logic from project-fork as loosely coupled as possible to avoid any potential conflicts.

2. Do not modify ANY of the original project-base models and instead create new models in different apps that reference the old models (i.e. using OneToOneField). Extra logic could end up in the old and/or new apps.

3. your idea here please :)

I would go with option 1 as it seems less complicated as a whole, but might expose a greater risk. Here's how I would see it happening:

Migrations on project-base:

• 0001_project_base_one
• 0002_project_base_two
• 0003_project_base_three

Migrations on project-fork:

• 0001_project_base_one
• 0002_project_fork_one

After merge, the migrations would look like this:

• 0001_project_base_one
• 0002_project_base_two
• 0002_project_fork_one
• 0003_project_base_three
• 0004_project_fork_merge_noop (added to merge in changes from both projects)

Are there any pitfalls using this approach? Is there a better way?

Thank you for your time.

Answer 1

Official South workflow:

The official South recommendation is to try with the --merge flag: http://south.readthedocs.org/en/latest/tutorial/part5.html#team-workflow

This obviously won't work in all cases, from my experience it works in most though.

Pitfalls:

• Multiple changes to the same model can still break
• Duplicate changes can break things

The "better" way is usually to avoid simultaneous changes to the same models, the easiest way to do this is by reducing the error-window as much as possible.

My personal workflows in these cases:

With small forks where the model changes are obvious from the beginning:

1. Discus which model changes will need to be done for the fork
2. Apply those changes to both/all branches as fast as possible to avoid conflicts
3. Work on the fork ....
4. Merge the fork which gives no new migrations

With large forks where the changes are not always obvious and/or will change again:

1. Do the normal fork and development stuff while trying to stay up to date with the latest master/develop branch as much as possible
2. Before merging back, throw away all schemamigrations in the fork
3. Merge all changes from the master/develop
4. Recreate all needed schema changes
5. Merge to develop/master