私は現在、Mercurial を使用したさまざまなローカル テスト リポジトリと South を使用した Django で、いくつかの複雑な移行をテストしています。
私が見つけようとしているのは;
- Mercurial は合併にどのように対処しますか
- マージされたファイルおよび/またはフォローアップファイルにサウスはどのように対応しますか
両方のケースの結論; 悪い..
問題1
Mercurial は、モデルのマージ自体を理解することはほとんどありません。非常に単純なフィールドの追加/削除でも、Mercurial Resolve(自動) 解決メソッドが失敗します。
問題 2
移行ファイルは、同期が取れなくなったり、うまく解決されなかったりする可能性があります。それを解決することは世界で最悪のことではありませんが、Mercurial のより大きなチーム ワーカーに大きなリスクをもたらします。
問題 3
同じモデルで 4 つの同時チェックアウトがあるとします。Appname/migrations/ここで、フォルダー内の複数の移行ファイルの移行番号が異なるか、異なるマージで同じであるという問題が発生します。
この複雑さがInconsistent Migration History問題を引き起こし、次のようになります。
InconsistentMigrationHistory: Inconsistent migration history
The following options are available:
--merge: will just attempt the migration ignoring any potential dependency conflicts.
--merge..ほとんど機能しないa が続き(; のようなものDatabaseError: (1091, "Can't DROP 'item_id'; check that column/key exists"))、多くの作業中のチーム メンバーの修正として依存するのは危険です。
migrations次のような方法でフォルダーをリポジトリから除外するのが賢明かどうか疑問に思っています。
syntax: regexp
^\w+/migrations/.*
私は現在、チーム メンバーに、モデル フィールドの変更を最初に主任開発者に報告するよう強制することを検討しています。
それに加えて、モデルが次のようにマージされるとしましょう：
オリジナルレポコード
class Sea(models.Model):
world = models.ForeignKey('World')
name = models.CharField(max_length = 45)
is_it_awesome = models.BooleanField(blank = True, verbose_name = 'Is it awesome?!')
description = models.TextField(blank = True)
チーム メンバー 1 のコード (コミット済み)
class Sea(models.Model):
world = models.ForeignKey('World')
name = models.CharField(max_length = 45)
description = models.TextField(blank = True)
チームメンバー 2 のコード
class Sea(models.Model):
world = models.ForeignKey('World')
name = models.CharField(max_length = 45)
is_it_awesome = models.BooleanField(blank = True, verbose_name = 'Is it awesome?!')
belongs_to_country = models.ForeignKey('Country', blank = True, default = None)
description = models.TextField(blank = True)
そのため、フィールドをTeam member 1削除しましたが、そのままにして追加しました。it_is_awesomeTeam member 2belongs_to_country
ここTeam member 2で、新しいコードを取り込み、Team member 1のコードと彼のコードの衝突を確認します。is_it_awesomeフィールドを保持するかどうか、および追加するかどうかを選択する必要がありますbelongs_to_country。そこで、彼は主任開発者のところにTeam Member 1行き、競合について話し合います。結論; is_it_awesome実際に行く必要がbelongs_to_countryあり、追加することができます。
Team Member 2チーム メンバーや主任開発者が行った選択とは異なる結果が生じた場合は、手動でマージを微調整する必要があります。
他の人がこれらの問題にどのように対処するのか、私のアプローチが問題ないのか、それとも問題を引き起こすのか疑問に思っています.
簡単に言えば、移行フォルダなしで安全に移行できますか? 私のもう1つの懸念は、サウスがデータベースに保持している履歴にも問題が発生する可能性があることです. すべてのチーム メンバーが、レポからのプル、マージ/解決の特定のパターンを維持し、それから新しい移行を行う必要があります。