south & version control
Radim
firstly, thanks for the great tool! I need some help understanding how
south operates with respect to distributed development.
Let's say there's a django app that I forked. I made some changes to
the models, created migrations -- all fine and works. Now, how do I
pull migration updates from the original repo?
I noticed south creates migration files with filenames that look like
sequence numbers -- so my own changes are called 007_xyz.py, while
upstream will have 007_abc.py. How is this conflict resolved in south?
What are the best practices for merging code from multiple locations?
Assuming the model changes are unrelated to each other, do I have to
rename the files before running a `migrate`, or can I keep them, or
must I somehow re-sculpt the migrations manually after merging the two
branches?
Sorry if the question is too fuzzy, I'm only starting my introduction
to the concept in south. Cheers,
Radim
Andrew Godwin
> Hi all,
>
> firstly, thanks for the great tool! I need some help understanding how
> south operates with respect to distributed development.
>
> Let's say there's a django app that I forked. I made some changes to
> the models, created migrations -- all fine and works. Now, how do I
> pull migration updates from the original repo?
>
> I noticed south creates migration files with filenames that look like
> sequence numbers -- so my own changes are called 007_xyz.py, while
> upstream will have 007_abc.py. How is this conflict resolved in south?
> What are the best practices for merging code from multiple locations?
The files are always run in pure ASCII sort order (that's why there's
leading zeros). In your example, abc comes first.
> Assuming the model changes are unrelated to each other, do I have to
> rename the files before running a `migrate`, or can I keep them, or
> must I somehow re-sculpt the migrations manually after merging the two
> branches?
>
> Sorry if the question is too fuzzy, I'm only starting my introduction
> to the concept in south. Cheers,
> Radim
Take a look at the last part of the tutorial for some docs that cover
how to merge changes.
Andrew
Carl Meyer
Hash: SHA1
Hi Radim,
On 02/04/2012 06:11 PM, Radim wrote:
> I noticed south creates migration files with filenames that look like
> sequence numbers -- so my own changes are called 007_xyz.py, while
> upstream will have 007_abc.py. How is this conflict resolved in south?
> What are the best practices for merging code from multiple locations?
>
> Assuming the model changes are unrelated to each other, do I have to
> rename the files before running a `migrate`, or can I keep them, or
> must I somehow re-sculpt the migrations manually after merging the two
> branches?
South orders migrations lexicographically by the full filename, not
solely by number. So in the case you describe, South will consider
"007_abc" as prior to "007_xyz". Because you already have applied
007_xyz, South will complain that you have out-of-order applied
migrations. You will have to first examine the migrations and determine
that they are in fact orthogonal, then run migrate with the --merge
option, which tells South to go ahead and just apply the out-of-order
migration without a rollback first. Then you should be fine; no need to
rename anything. (The other developer, who created 007_abc, won't have
this problem because South considers your 007_xyz to be a later
migration anyway).
The last thing you have to do in this case (only if you are using
South's model-freezing and auto-detection) is create a no-op "empty"
migration that will contain the true up-to-date frozen model
definitions, so future change-detection works correctly (because the
frozen model definitions in 007_xyz don't reflect the model changes in
007_abc). This empty migration is sort of equivalent to a VCS merge commit.
If the two 007 migrations do in fact conflict at the database level,
then at least one of you simply has to roll back your database to the
prior state, remove your migration, and replace it with a new one that
accounts for the other changes.
> Sorry if the question is too fuzzy, I'm only starting my introduction
> to the concept in south. Cheers,
This is a very common question. I think some of what I wrote above is
already in the documentation. If you find what I wrote helpful, perhaps
you'd be willing to propose a documentation patch including (or more
fully explaining) the key points that the current docs failed to
communicate adequately to you?
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8ytNYACgkQ8W4rlRKtE2feqACaA5qmbFxmUgf9YJ4zVXsDNjTc
RtgAnjGymwCy5FQtKoFgaRsIS6FP3mac
=XUwi
-----END PGP SIGNATURE-----