Option to use timestamp migrations rather than serial number

[msabramo@…]

The serial numbers work great most of the time, but we recently ran into a fair amount of trouble when multiple developers were changing (different) models in a project on different branches. Because each developer is on a branch and doesn't see the migrations that developers on other branches are generating, it is extremely easy for the serial numbers to collide and then it's a mess to sort through after merging.

Timestamped migrations don't completely eliminate the problems with working on multiple branches -- differing frozen ORM state is also a problem, but they at least make it easier to see what happened and to sort through the migrations a bit more easily.

Since this is a huge change in how South works, I would implement this as an option that defaults to False.

[anonymous]

Pull request on bitbucket: ​https://bitbucket.org/andrewgodwin/south/pull-request/8/option-to-use-timestamp-migrations-rather

[anonymous]

Here's what it looks like in action:

$ ./manage.py schemamigration publisher --auto
...
 + Added field foobar on publisher.Tag
...
Created 2011-09-28T05:52Z_marcabramowitz.py. 
You can now apply this migration with: ./manage.py migrate publisher

[msabramo@…]

Here is why Rails switched from serial numbers to time stamps:

​http://guides.rubyonrails.org/migrations.html#what-s-in-a-name

[andrew]

I've WONTFIXed this before, and I'm afraid I'm going to have to do so again.

Firstly, South does not identify migrations by the number; in fact, it does nothing special, and just ASCII-sorts them (so, as you know, switching to dates is easy, and you can do it manually if you want to). That means that, even if two migrations have the same number, there is still a fixed, implicit ordering - unlike Rails, where they (I believe) just used the number, and so it went all wibbly.

Adding dates does not prevent clashes; it merely moves that clash somewhere else. If I add a migration and someone else does at roughly the same time, after a merge we're still going to have a hole in our migration history.

(Unlike Rails, South won't just run missed in-the-middle migrations, you need to pass --merge)

Additionally, using dates presents further potential problems; I know many machines that do not have a correct UTC clock setting (be they sharing with Windows and not set up right, drifted non-NTP machines, or VMs that have no RTC).

Basically, I see no concrete improvement that adding dates brings, and I see one concrete downside - harder-to-type migration names.