[Django]-What's the recommended approach to resetting migration history using Django South?

If you need to selectively (for just one app) reset migrations that are taking too long, this worked for me.

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

Don’t forget to manually restore any dependencies on other apps by adding lines like depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial")) to your <app-dir>/migrations/0001_initial.py file, as the first attribute in your migration class just below class Migration(SchemaMigration):.

You can then ./manage.py migrate <app-name> --fake --delete-ghost-migrations on other environments, per this SO answer. Of course if you fake the delete or fake the migrate zero you’ll need to manually delete any left-over db tables with a migration like this.

A more nuclear option is to ./manage.py migrate --fake --delete-ghost-migrations on the live deployment server followed by a [my]sqldump. Then pipe that dump into [my]sql on the environments where you need the migrated, fully-populated db. South sacrilege, I know, but worked for me.

Thanks to the answers by Dominique Guardiola and hobs, it helped me solve a hard problem.
However there are a couple of issues with the solution, here is my take on it.

Using manage.py reset south is not a good idea if you have any third party apps that uses South, for example django-cms (basically everything uses South).

reset south will delete all migration history for all apps that you have installed.

Now consider that you upgrade to the latest version of django-cms, it will contain new migrations like 0009_do_something.py. South will surely be confused when you try to run that migration without having 0001 through 0008 in the migration history.

It is much better/safer to selectively reset only the apps that you are maintaining.

First of all, make sure that your apps don’t have any desync between migrations on disk, and migrations that have been executed on the database. Otherwise there will be headache.

1. Delete migration history for my apps

sql> delete from south_migrationhistory where app_name = 'my_app';

2. Delete migrations for my apps

$ rm -rf my_app/migrations/

3. Create new initial migrations for my apps

$ ./manage.py schemamigration --initial my_app

4. Fake execute the initial migrations for my apps

This inserts the migrations into south_migrationhistory without touching actual tables:

$ ./manage.py migrate --fake my_app

Step 3 and 4 is actually just a longer variant of manage.py convert_to_south my_app, but I prefer that extra control, in such delicate situation as modifying the production database.

Like thnee (see her answer), we’re using a gentler approach to the South author’s (Andrew Godwin) suggestion quoted elsewhere here, and we’re separating what we do with the code base from what we do to the database, during deployment, because we need the deployments to be repeatable:

What we do in the code:

# Remove all the migrations from the app
$ rm -fR appname/migrations
# Make the first migration (don't touch the database)
$ ./manage.py schemamigration appname --initial

What we do to the database once that code is deployed

# Fake the migration history, wiping out the rest
$ ./manage.py migrate appname --fake --delete-ghost-migrations

If you are just working on the dev machine, I wrote a management command that does pretty much what Dominique suggested.

http://balzerg.blogspot.co.il/2012/09/django-app-reset-with-south.html

In contrast of the south author suggestion, this will NOT HARM other installed apps using south.

Following is only if you want to reset all apps. Please backup your all databases prior to that work. Also note down your depends_on in initial files if there are any.

For once:

(1) find . -type d -name migrations -exec git rm -rf '{}' \;
(2) find . -type d -name migrations -exec rm -rf '{}' \;
(3) ./manage.py schemamigration <APP_NAME> --initial
(4) [GIT COMMIT]

Test bootstrapping your project before push. Then, for each local/remote machine, apply following:

(5) [GIT PULL]
(6) ./manage.py reset south
(7) ./manage.py migrate --fake

Do initial (3) for each app you want to re-involve. Note that, reset (6) will delete only migration history, therefore not harmful to libraries. Fake migrations (7) will put back migration history of any 3rd party apps installed.

delete necessary file from app folder

instance path

 cd /usr/local/lib/python2.7/dist-packages/wiki/south_migrations

wiki -is my app