python - 南方移民和 Mercurial

Question

我目前正在使用 Mercurial 和 Django 使用 South 在不同的本地测试 Repo 中测试一些复杂的迁移。

我想知道的是;

1. Mercurial 将如何处理合并
2. South 将如何回应合并和/或后续文件

两种情况的结论； 不好..

问题一

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 (类似的东西； DatabaseError: (1091, "Can't DROP 'item_id'; check that column/key exists")) 并且再次成为许多工作团队成员依赖的风险解决方案。

我想知道从存储库中排除 migrations 文件夹是否明智；

syntax: regexp
^\w+/migrations/.*

我目前正在考虑是否可以强制团队成员至少首先向首席开发人员报告模型字段中的更改。

除此之外，我认为当假设一个模型将像这样合并时:

原始 repo 代码

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_awesome 字段，但 Team member 2 保留了它并添加了 belongs_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 如果 Team members 和/或 Lead Developer 做出的选择有不同的结果，仍然需要手动调整合并。

我想知道其他人是如何处理这些问题的，我的方法是否可行或仍然会带来问题。

长话短说；我可以在没有迁移文件夹的情况下安全迁移吗？我的另一个担心是它可能会导致 South 保存在数据库中的历史出现问题。这将要求所有团队成员保持某种模式，即从 repo 中拉取、合并/解析，然后才进行新的迁移。

Answer 1

问题1

https://www.mercurial-scm.org/wiki/TutorialConflict

你会发现的唯一冲突是当 2 个人触摸相同的代码时，mercurial 要求你进行干预是 100% 正确的。

问题2

您应该先阅读 South 文档:Part 5: Teams and Workflow

确保当员工将他们的分支合并到开发/集成分支时，如果需要在其他所有分支之后运行，他们将迁移移动到下一个最高编号，否则您可以使用 --merge 很好。

问题3

开发者2在集成他的分支之前，应该将当前的开发版本合并到自己的分支中，并解决冲突。只有当冲突解决后，他才能将其合并回开发分支。

或者，您有一个“首席开发人员”充当看门人，负责将功能拉入集成分支并对冲突采取行动。

始终将您的迁移存储在代码库中。不要排除迁移。它们是代码，就像您的其余代码一样，合并时必须考虑迁移。投入时间和精力来妥善维护它们，您将获得 10 倍的返回。