3

以下は、Team Workflowに関する South の公式ドキュメントのセクションから抜粋したものです。

2 番目に注意すべきことは、他の誰かのモデルの変更を自分の移行で完全に取り込む場合、開発の両方のブランチからの変更が凍結された新しい空の移行を作成する必要があるということです (mercurial を使用した場合)。 、これはマージコミットと同等です)。

この場合、新しい空の移行を作成する必要がある理由がわかりません。./manage.py migrate開発者は、モデルの変更 (および対応する移行) を他のユーザーから取得した後に実行するだけでよいのではないでしょうか? ここで何が欠けていますか？

4

2 に答える 2

1

これが意味することは、両方のブランチに同じモデルへの変更がある場合、コードをマージして、それらの変更に対して単一の移行スクリプトを再作成する方がよいということです。これは、branch1 に 0006 移行スクリプトがあり、branch2 に別の 0006 移行スクリプトがある場合 (south が順番に名前を付ける方法を知っています...)、実際には異なるファイルであるため、それらを正しく自動マージできないためです。

したがって、コードの変更をマージしてから、マージされたブランチの移行スクリプトを再作成する必要があります。

于 2012-07-13T20:20:29.317 に答える
1

この作品に関連する問題がありました。モデルがあるとします:

class Article(Model):
    title = CharField()

開発者 1 は、たとえば、author自分のブランチにフィールドを追加します (移行により、タイトル、作成者が凍結されます) 開発者 2 は、date_published自分のブランチにフィールド 、を追加します (移行により、タイトル、date_published が凍結されます)

次に、誰かが 2 つのブランチをマージします。date_published彼らが得るのは、1 つはfieldについて知らず、もう 1 つは見たことのない 2 つの移行authorです。

これがもたらす可能性があるのは、次回自動移行を作成するときに、オーサーまたは date_published フィールド (最後に追加された移行が何であれ) を追加しようとすることです。これは、100% 正しいデータベースの状態がわからないため、移行内で凍結されていないためです。

于 2012-07-14T00:35:34.823 に答える