17

I'm wondering whats the "best" way to use South with multiple developers.

Should the migration files be tracked? The problems rise when two developers create different changes to models.py from a same origin.

If the migration files are tracked:

  1. It is difficult to notice a merge is needed since they are formed with different file names.
  2. and it is difficult to merge anyway.
  3. difficult to apply (need to migrate backwards one migration, merge, migrate forward again)

If they are not tracked:

  1. tweaking migrations can't be shared.
  2. a developer needs to create a migration (and apply it) whenever he pulls a change to models file (instead of just applying it).

Are there more advantages/disadvantages I missed? whats the "best" way? I'm currently using tracked migrations but thinking of changing to untracked, seems its far simpler.

thanks.

Iftah
  • 9,512
  • 2
  • 33
  • 45
  • Shouldn't developers commit migrations that are not going to break the models? as in make sure you update to the latest first? – James Khoury May 30 '11 at 07:01
  • Yes, before commiting you should pull and *merge* and make sure its not broken before you push your changes. When two developers work in parallel and clash with different changes to models.py this merge is exactly the problematic part I'm trying to avoid - the code merge is easy, the migration merge is hard. – Iftah May 30 '11 at 07:47

1 Answers1

21

They should definitely be added to source control. You will need to manually (verbally?) co-ordinate changes your models to avoid clashes. If you don't include the migrations in your source control, then other developers won't be able to migrate their database (which defeats the point of actually having migrations).

bradley.ayers
  • 37,165
  • 14
  • 93
  • 99
  • 2
    as long as you permit only --auto created migrations (ie no tweaking) then other developers can create the needed migrations locally. In the end after merging the models.py file both developers will have same database schema, just different set and different order of migrations. As long as only --auto migrations are used I don't see a problem. – Iftah May 30 '11 at 07:39
  • 11
    I should have RTFM more deeply, the tutorial talks about collaboration in chapter 5 [http://south.aeracode.org/docs/tutorial/part5.html#team-workflow]. To my defense, there is a bug in the documentation and when reading chapter 4 the "next chapter" skips chapter 5. The tutorial clearly recommends to track the migration files, so I'm accepting this answer but recommend future readers to check what the tutorial says about this. – Iftah May 30 '11 at 09:27