Missing migration for Revision.project null=True about codespeed

[tobami]

It is for historical reasons. Migrating from Revision->Project to Revision->Branch->Project was a bit messy (there are several scripts to migrate an old DB). In order for the migration to work, revision.project was left there.

I also do not like that python manage.py syncdb doesn't leave you with a new, clean DB. You need an extra step.

It would be a task for the next release (1.0.0?) to remove this migration artefact.

[squiddy]

I also do not like that python manage.py syncdb doesn't leave you with a new, clean DB. You need an extra step.

Agreed. It probably is helpful to users migrating projects across releases, but is has its downsides (spending hours trying to migrate complex schema changes - what some lines of SQL can achieve).

But the issue is still there. I had to add a migration in two branches now to keep the commits separated. Should we include the migration that is missing (to have a clean base) or remove Revision.project right away? In my opinion, one of these should be done, if you plan to keep using south.

[tobami]

IMO removing Revision.project would be a cleaner solution looking forward

[squiddy]

Alright, I'll send a pull request then.

[tobami]

@squiddy do you intend to send a pull request for this yet?

[squiddy]

Yes, I'll send one today. Better late than never.

[tobami]

Great, thanks

[squiddy]

Hm, I underestimated the work involved. I doubt I'll have time for this.

First thing I noticed is that there seems to be a migration conflict. Two migrations occupy the same timeslot, 0011. Apparantly the conflict was not resolved, therefore south does not detect the 'commit_browsing_url' migration here and wants to create a new one. I don't know if recreating it as 0012 and deleting the old is enough.

Removing Revision.project breaks a lot of API tests. I had a quick look at the code, but it would take some time to understand it. Maybe a8 can help here?

[tobami]

Migrations are clean now