如何在大型团队项目

Question

在工作中，我们需要重新组织我们的版本控制系统。

项目结构如下：

2个团队： Team1 和 Team2

a） Team1 和 Team2 都在模块 A 上工作。

b） Team1 也适用于 B 和 C ，它们依赖于 A 。

c） Team2 也适用于 D ，这取决于 A ， B 和 C

我们不希望 Team2 在其本地计算机上实际拥有 B 和 C （属于 Team1 ）同时我们不希望 Team1 拥有 D 。

目标是及时获得项目的完整快照，即我们希望随时跟踪和回滚到整个项目的给定版本。

我们考虑过使用Mercurial subrepos，但似乎不可能（或许）团队忽略其他团队的subrepos。每个人都必须拉动每个subrepo。它是否正确？

如果是这样，我们怎样才能克服这一点？我们是否真的需要拥有三个完全独立的存储库，并手动跟踪 B + C 的代码 A 的兼容版本，以及 D < / em>的

我们担心这种手动跟踪会随着时间的推移而出现错误。

Answer 1

您可以使用subrepos并组织为：

• Team1使用主回购 X ，其中包含 A ， B 和 C 。
• Team2使用主要回购 Y ，使用subrepos A 和 D 。

如果B和C不相关，您可能需要：

• Team1使用主回购 B ，其中包含 A 。
• Team1使用主回购 C ，其中包含 A 。
• Team2使用主回购 D 与subrepo A 。

如果A发生变化，团队可以选择是否以及何时将A subrepo更新为新的变更并将其提交给他们的主仓库。

Answer 2

团队很容易忽略另一个团队的副本。他们只需要在父仓库中使用不同的分支，其中.hgsub文件只包含该分支所需的子版本。

我建议没有多个主回购，但只有一个拥有这三个分支的主回购：

• 分支“Team1”在其.hgsub文件中只有subrepos A，B和C.
• 分支“Team2”在其.hgsub文件中只有子目录A和D.
• 分支“全部”（或默认）在其.hgsub文件中包含A，B，C和D.

当团队1从分支团队1中退出时，他们得到A，B和C.团队2从分支团队2中检出，他们只得到A和D.整个项目的经理使用分支“全部”（或默认情况下），并将所有repos A，B，C和D更新到适当的版本，然后提交，将所有repo版本绑定在一起并获得所需的完整快照。