2

[注意：“Perfarce”是与 Perforce 集成的 Mercurial 扩展名：https ://www.mercurial-scm.org/wiki/PerfarceExtension ]

我们开始为当前存储在 Perforce 中的项目评估 Mercurial。与其放弃 P4 仓库并在 ​​Hg 中进行所有更改，我们希望主要在 Hg 中工作并定期将更改推送到 P4。在此评估期间，一些开发人员可能会继续在 Perforce 中工作，但除此之外，我们还想评估 DVCS 使之成为可能的工作流程，例如从一个开发人员的 repo 拉到另一个。

我已经尝试过 Perfarce 扩展，它看起来是使用 Hg 作为具有更精细本地历史的高级 P4 客户端的好方法。然而，当我使用 Perfarce 在两台不同的机器上检查同一棵树时，我得到了两个具有不同变更集 ID 的 Mercurial 历史记录。看起来以这种方式共享更改的唯一方法是通过 P4 仓库。

是否有其他选项可以使开发人员的存储库与 P4 同步，而不会使它们在 Mercurial 级别不兼容？

4

1 回答 1

4

老实说 - 这听起来像是一种可能导致噩梦的情况。以下是我将如何处理它以最大程度地减少一些风险和痛苦：

  • 将 Perforce 工作区设置为“ allwrite ”，这样 Perforce 就不会过多地干扰 Hg。
  • 使用单个 P4 工作区将更改从 depot 同步到 mercurial 存储库（以及从 hg 返回到 depot），然后从中执行您的 mercurial 推/拉工作。将其视为 GitHub 或 Bitbucket 上的主存储库。
  • 通过使用 P4V 的“协调离线工作”功能，使用 one-true-workspace 同步更改回 Perforce，并确保仔细查看更改列表（您不想提交 .hg 目录）。

通过一些纪律，您应该能够避免一些陷阱，尽管这肯定不是一个理想的前进道路。我不认为有一个项目符号可以让您无缝地保持您的更改在所有不同的存储库中正确镜像，并让每个人都像往常一样工作。

于 2012-07-17T23:29:15.070 回答