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.

---

EDIT - I'm putting a comment below at the top of this as it's important to read it before the > accepted answer that follows @andybak @Dominique: Your advice regarding manage.py reset south is dangerous and may destroy the database if there are any third party apps using south in the project, as pointed out by @thnee below. Since your answer has so many upvotes I'd really appreciate it if you could edit it and add at least a warning about this, or (even better) change it to reflect @hobs approach (which is just as convenient, but doesn't affect other apps) - thanks! – chrisv Mar 26 '13 at 9:09 Accepted answer follows below:

First, an answer by the South author:

As long as you take care to do it on all deployments simultaneously, there shouldn't be any problem with this. Personally, I'd do: rm -r appname/migrations/ ./manage.py reset south ./manage.py convert_to_south appname (Notice that the “reset south” part clears migration records for ALL apps, so make sure you either run the other two lines for all apps or delete selectively). The convert_to_south call at the end makes a new migration and fake-applies it (since your database already has the corresponding tables). There's no need to drop all the app tables during the process.

Here's what I'm doing on my dev + production server when I need to get rid of all these unneeded dev migrations:

Make sure we have the same DB schema on both sides delete every migrations folder on both sides run ./manage.py reset south (as the post says) on both sides = clears the south table * run ./manage.py convert_to_south on both sides (faking 0001 migration) then I can re-start to make migrations and push the migrations folders on my server

* except if you want to clean only one app among others, if so you'll need to edit your south_history table and delete only the entries about your app.

---

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

---