[注意:“Perfarce”是用于与 Perforce 集成的 Mercurial 扩展的名称:https://www.mercurial-scm.org/wiki/PerfarceExtension ]
我们开始针对当前存储在 Perforce 中的项目评估 Mercurial。我们不想放弃 P4 仓库并在 Hg 中进行所有更改，而是希望主要在 Hg 中工作并定期将更改推送到 P4。在此评估期间，一些开发人员可能会继续在 Perforce 中工作，但除此之外，我们希望评估 DVCS 实现的工作流程，例如从一个开发人员的存储库拉到另一个开发人员的存储库。
我已经尝试过 Perfarce 扩展，它看起来是使用 Hg 作为具有更精细的本地历史记录的高级 P4 客户端的好方法。然而，当我使用 Perfarce 在两台不同的机器上检查同一棵树时，我得到了两个具有不同变更集 ID 的 Mercurial 历史记录。看来以这种方式共享更改的唯一方法是通过 P4 仓库。
是否有其他选项可以使开发人员的存储库与 P4 保持同步，而又不会使其在 Mercurial 级别不兼容？
最佳答案
老实说 - 这听起来像是一种可能导致噩梦的情况。以下是我将如何尽量减少风险和痛苦的方法:
- 将 Perforce 工作区设置为“allwrite ”，这样 Perforce 就不会过多干扰 Hg。
- 使用单个 P4 工作区将更改从 depot 同步到 Mercurial 存储库(以及从 hg 同步回 depot)，然后从中执行 Mercurial 推/拉工作。将其视为 GitHub 或 Bitbucket 上的主存储库。
- 通过使用 P4V 的“协调离线工作”功能，将单一真实工作空间同步更改回 Perforce，并确保仔细检查更改列表(您不想提交 .hg 目录)。<
通过一些纪律，您应该能够避免一些陷阱，尽管这肯定不是理想的前进道路。我不认为有任何一个项目可以让您无缝地将更改正确地镜像到所有不同的存储库并允许每个人照常工作。
关于mercurial - 推荐使用 Perfarce(或其他？)来评估 Mercurial 工作流程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11529756/