如何在不丢失历史记录的情况下将大型Perforce存储库导出到不同的版本控制系统？

Question

在工作中，我们拥有一个庞大的Perforce存储库（大约40,000个更改列表，总存储大小~145GB）。我们对Perforce只有一些温和的抱怨感到满意，但我们计划采用更加分散的开发模式，因此，我们也希望转向更加分散的版本控制系统。

到目前为止，我已经看过通常的嫌疑人（git，mercurial和潜在的市集，因为我对它有很好的经验），但我们目前的主要障碍是将版本历史记录从Perforce中导入并导入到各种DVCS中，以便我们不会失去历史。如果我们不一定要保留它，我们也不希望Perforce服务器闲置 - 我对这种迁移的体验是，一段时间后没有人看过旧的仓库，所以你会失去历史那样。

由于存储库中有多个项目，我们的想法是在导出历史记录时将其拆分为多个DVCS项目，因为并非每个人都需要能够查看历史记录的每个部分。然而，我们最大的项目仍然包含大约2/3的承诺修订版，并且还占用了大约2/3的存储空间。它也拥有最多的分支机构 - 可能大约30个。

到目前为止，我已经尝试了以下内容 - 所有内容都在Windows上，因为我们只是一个仅限Windows的商店：

• 使用hg convert扩展程序导入Mercurial。这似乎对我正在转换的项目的主分支非常有效，但是尝试使用分支图将Perforce分支转换为命名的Mercurial分支仍然会在默认分支上的每个签入时生成平面导入。也许那是因为我设置了分支映射错误，但是hg help convert表明你只能将Perforce repo变成一个“扁平”结构而没有使用这个导入器的分支，这对我们的使用来说还不够好。
• 使用git-p4.py导入Git。 Perforce文档使用git作为Perforce的分布式前端，并且基于repo的最新版本的关闭确实产生了一个可用的git repo。尝试使用分支导入整个子项目会导致导入器耗尽内存，因此我甚至无法判断它是否设法正确导入我们的仓库。
• 然后我有了这个辉煌的大脑放屁，将Perforce repo导入SVN，所有分支都映射到适当的SVN分支，因为太阳下的每个版本控制系统都可以从SVN导入。这只是使用SVN作为转换的中间步骤，而不是目标VCS - 否则我们不会从这个转换中获得任何东西。使用p42svn.pl，因为我们的Perforce服务器似乎不喜欢被似乎为每个文件/版本建立新连接的脚本所打击，所以p42svn.pl在这个过程中很早就破坏了。
• 我还没有考虑将历史出口到Bazaar，因为它有点像跑步。

所以，我的问题是：

• 除了p42svn.pl之外还有一个很好的工具可以将Perforce repo导出到SVN吗？我不介意使用SVN作为中间回购，因为它似乎导致导出到我们看起来相当容易的所有DVCS。
• 是否有人成功将Perforce的分支机构导出到Mercurial名为分支机构，如果是，您是如何做到的？关于转换扩展的文档似乎有点稀疏，我似乎无法找到一个好的/工作方式来做到这一点。

Answer 1

如您所知，切换源控制系统是一项巨大的任务，不能掉以轻心。由于 1）进行了实际转换，因此存在相当大的风险和停机时间，而 2）则会再次出现，因为每个人都需要重新设置工具并快速了解新系统。

在您仍在调查您的选项时，我会认真地深吸一口气，然后查看 P4 Sandbox ，看看是否符合您的要求。

有关P4 Sandbox的更多信息如下。

<强>概述
- P4Sandbox Feature Demo (Video)

博客帖子
- P4Sandbox Private local branching, distributed development, and more
- P4Sandbox’s First Submit
- Distributed Development and P4Sandbox
- Private Branching with P4Sandbox
- Task-focused Work in P4Sandbox

论坛讨论
- New Features Discussion on the official forums

Answer 2

我的话，您的存储库大小几乎是200 GB？我为第一个获得git pull获取存储库副本的傻瓜感到遗憾，并发现他们现在正在下载价值150千兆字节的数据。

我的建议：不要打扰整个历史。您真正需要的只是活动版本和分支。可以把它想象成一个抛弃枯木并重组你的存储库的机会。

我曾经主张尽可能多地获取历史记录，但有一天我不得不将StarTeam存储库转换为ClearCase，而这是无法完成的。 StarTeam中的命令行工具很差，API无法满足我的需求。

我们只是下载了客户拥有的版本，我们正在处理的分支机构以及源代码的几个版本。我们保留了旧的StarTeam服务器，以防万一有人可能需要查看源代码，但没有人这样做。

但是，如果你想要通过这个，那真的不应该那么糟糕。您可以编写Python或Perl脚本来为您进行转换。

Perforce通过编号的变更集跟踪历史记录。是的，每个文件都有自己的版本号，但你真的不太感兴趣，你对更改集更感兴趣。

如果您的P4上次更改集为1,000，则可以将更改集1循环到1,000。 Perforce有时会跳过变更集，但这很容易被发现。每个变更集都有一个日期，进行该提交的人员的姓名以及他们的评论。有了这些信息，您可以将更改推送到Git存储库，并更改该提交的date, author, and comment。

顺便说一下，既然你正在转向Git，我希望你能将你的存储库拆分成单独的存储库。而且，如果您提交了构建对象，请在将它们移动到Git之前将它们从Perforce存储库中删除。您永远不应该在存储库中存储构建的对象 - 特别是如果它们是二进制的。它们占用了大量空间，并且很快就会过时。

Answer 3

我们（我在perforce工作）构建的产品确实为Perforce软件仓库提供了一个git接口。

http://www.perforce.com/product/components/git-fusion

我在内部使用了一年以上，这很棒，因为您可以使用“实时”Perforce后端尝试新的DVCS方法（您需要多少个回购）。我是唯一使用git的团队成员，而其他人都使用p4或p4v。因此，人们可以使用git工作并逐步确定您的迁移配置。

支持在两个系统之间映射分支： http://www.perforce.com/perforce/doc.current/manuals/git-fusion/index.html#chapter_dyn_ngj_3l.html#section_kkz_gqv_rl

我不确定这是否解决了上述所有系统，因为我确信你只能从git转到X.