How to keep multiple machines synchronized with south and git

Question

So, although I like South, I had persistent problems with this particular workflow:

• transfer several times to machine A
• periodically push changes to git
• after a long period, return to car B
• pull from Git and redirect various errors for machine B

These errors are usually "table already exists" errors.

Now I have read numerous blog posts and stack questions, and frankly, there is no clear answer to how to check migration files (and whether it is necessary at all) and how to integrate South with Git really.

What I'm looking for is a detailed run of how to properly use Git and South together and show how the workflow between the two machines will work.

Currently, what I need to do is after a while completely clear the migration folders and start from scratch. It doesn't seem like a good way to handle things.

Answer 1

I would really like to know where there was doubt that it was necessary to register the migration files of the South. Of course, I did not know about any assumptions that you did not.

In your workflow, you will not indicate whether machines A and B use the same or different databases. If your code will differ significantly between the two machines, then they should use different databases. If the database schema is ahead of the code, you will get errors. Obviously, the circuit cannot lag behind the code, because you should always run migrate after updating the code.

My workflow is as follows:

 A: create schema migrations and apply as they are created. A: add schema migration files to subversion and commit B: svn up B: python manage.py migrate B: continue coding! 

Since migration files may contain code that converts data to a database, you should not delete migrations because you will lose this code. I have a development team of three people who created 80+ migrations and did not encounter any problems of the form you describe.

Answer 2

Problem

south and team workflow appears when two people create a migration without synchronizing with each other.

Imagine we have some repo. Faces A and B clone it, then change some model, create a migration, and then push it all back. We will have 2 migrations with the same number in the repo.

The South will complain if you try to make a migration with such a story.

 Inconsistent migration history The following options are available: --merge: will just attempt the migration ignoring any potential dependency conflicts. 

As stated in the southern docs at http://south.readthedocs.org/en/latest/tutorial/part5.html , you can try using the --merge option, and the south will try to combine the migrations. It will not work if conflicting migrations change the same model (s).

 ./manage.py schemamigration --auto --merge appname 

So, the basic rule for the team: at one time, only one developer could change one model. If someone started changing the model, no one should touch it until they have the migration files.

Rules for a team workflow with south and multiple git branches:

• Before making changes to double-checking the model, if someone is already making changes there
• Notify other members of your changes as soon as possible.
• Sync migration directories as soon as possible

Also from the southern docs: when you pull in some changes to the elses model complete with their own migration, you need to make a new empty migration that has changes from both development branches frozen in (if you used mercurial, this is equivalent to merging) . To do this, simply run:

  ./manage.py schemamigration --empty appname merge_models 

merge_models there is only a new migration name

Group workflow rules with south and single git branch:

If all members of your team make one separation, the best strategy is to first make model changes, make migration, and direct it as soon as possible. Then work on another code.

These articles may also be of interest to you:

http://andrewingram.net/2012/dec/common-pitfalls-django-south/ http://anthony-tresontani.imtqy.com/Django/2013/03/15/south-workflow/