推荐的Perfarce(或其他?)用法来评估Mercurial工作流程

时间:2012-07-17 19:43:25

标签: mercurial perforce perfarce

[注意:" 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仓库。

还有其他选择来保持开发者和#39;存储库与P4同步而不会使它们在Mercurial级别不兼容?

1 个答案:

答案 0 :(得分:4)

老实说 - 这听起来像是一个可能导致噩梦的情况。以下是我如何处理它以尽量减少风险和痛苦:

  • 将Perforce工作区设置为“allwrite”,以便Perforce不会对Hg造成太多干扰。
  • 使用单个P4工作区将更改从软件仓库同步到mercurial存储库(以及从hg返回到软件仓库),然后从中进行mercurial推/拉工作。它有点像GitHub或Bitbucket上的主存储库。
  • 使用one-true-workspace同步更改回Perforce,使用P4V的“协调脱机工作”功能,并确保仔细查看更改列表(您不想提交.hg目录)。

有了一些纪律,你应该能够避免一些陷阱,虽然它肯定不是一个理想的前进道路。我认为没有一个子弹可以让您无缝地保持您的更改在所有不同的存储库中正确镜像,并允许每个人像往常一样工作。