如何在大型团队项目中组织 Mercurial 存储库/子存储库

How to organize mercurial repository / subrepositories in large team project

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

项目结构如下:

2 支球队:Team1Team2

a) Team1Team2 都在模块 A.[=10= 上工作]

b) Team1 也适用于 BC,这取决于 A.

c) Team2 也适用于 D,这取决于 A BC

我们不希望 Team2 在他们的本地计算机上实际拥有 BC(属于Team1)同时我们不希望Team1D.

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

我们考虑过使用 Mercurial subrepos,但一个团队似乎不可能(也许)忽略另一个团队的 subrepos。每个人都必须拉动每个子回购。这个对吗?

如果是这样,我们该如何克服呢?我们真的需要拥有三个完全独立的存储库并手动跟踪代码 AB+C 的兼容版本,并且分别地, D?

我们担心这种手动跟踪随着时间的推移容易出错。

您可以使用 subrepos 并组织为:

  • Team1 使用主仓库 X 和子仓库 A​​BC.
  • Team2 使用主仓库 Y 和子仓库 A​​D.

如果 B 和 C 无关,您可能需要:

  • Team1 使用主存储库 B 和子存储库 A​​.
  • Team1 使用主存储库 C 和子存储库 A​​.
  • Team2 使用主仓库 D 和子仓库 A​​.

如果 A 更改,团队可以选择是否以及何时将 A 子仓库更新为新更改并将其提交到他们的主仓库。

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

我建议不要有多个主存储库,而只有一个包含这三个分支的主存储库:

  • 分支 "Team1" 在其 .hgsub 文件中只有子库 A、B 和 C。
  • 分支 "Team2" 在其 .hgsub 文件中只有子库 A 和 D。
  • 分支 "All"(或默认)在其 .hgsub 文件中有 A、B、C 和 D。

当团队1从分支team1签出时,他们得到A,B和C。团队2从分支team2签出,他们只得到A和D。整个项目的经理使用分支"All"(或默认),并将所有存储库 A、B、C 和 D 更新为适当的版本,然后提交,以将所有存储库版本绑定在一起并获得所需的完整快照。