Perforce 如何识别/验证Performce历史记录中的完整集成点

在分析perforce仓库的历史时，我需要确定从另一个分支执行完全集成的那些变更，并找出该集成源的确切变更编号。不幸的是，尽管这种完全集成是一种常见的操作，但我在历史上找不到任何简单可靠的方法来检测它。如果我错过了什么，请告诉我

在任何情况下：通过使用“p4 filelog”并匹配修订号的一组脚本，我设法找到了所有候选更改及其各自的集成源更改。我所缺少的是一种区分完全集成和仅限于子目录的部分集成的方法。为此，我能找到的最接近的命令是'p4 interchanges'，它完全满足我的需要，除了'toFile'参数不能有'@'版本规范的问题

我希望

p4 interchanges //depot/sourcebranch@123400 //depot/targetbranch@123499

将告诉我在我找到的集成点中是否缺少任何更改，但它只给出了错误“此处无法使用修订规范（#或@）”-这与文档匹配

---

是否有其他方法来检查p4历史记录中的积分点，以区分完全合并和完全合并？

使用undoc

p4 integ-C changelist

命令：

p4 integrate -1 -2 -C changelist# -Rlou -Znnn
    ...  The -C
    changelist# flag considers only integration history from changelists
    at or below the given number, allowing you to ignore credit from
    subsequent integrations.  ...

因此：

p4 integ -n -C 123499 //depot/sourcebranch/...@123400 //depot/targetbranch/...

我应该告诉你sourcebranch@123400完全融入到targetbranch@123499. 如果在理论上使用

-C 123498

，则输出中的差异将显示集成了哪些文件

删除的文件可能存在一些边缘情况——例如，如果您将删除的文件集成到头部修订时删除的文件中，无论集成历史如何，它都会报告“最新”，因此，我可以想象，由于这个原因而被跳过但随后又重新添加的文件可能会用上述方法给出假阳性。（或者它可能不会——我对可能修复该场景有模糊的记忆，但undoc错误修复不会出现在relnotes中…）

下面是一个例子foo@2被纳入bar@3:

sams-mbp:test samwise$ p4 filelog ...
//stream/main/test/bar
... #2 change 4 delete on 2019/07/21 by samwise@samwise-dvcs-1517552832 (text) 'delete'
... #1 change 3 branch on 2019/07/21 by samwise@samwise-dvcs-1517552832 (text) 'branch'
... ... branch from //stream/main/test/foo#1
//stream/main/test/foo
... #2 change 6 edit on 2019/07/21 by samwise@samwise-dvcs-1517552832 (text) 'edit'
... #1 change 2 add on 2019/07/21 by samwise@samwise-dvcs-1517552832 (text) 'add'
... ... branch into //stream/main/test/bar#1


sams-mbp:test samwise$ p4 integ -n -C 2 foo@2 bar
//stream/main/test/bar#2 - branch/sync from //stream/main/test/foo#1
sams-mbp:test samwise$ p4 integ -n -C 3 foo@2 bar
foo@2 - all revision(s) already integrated.

---

使用

-c2

（在分支之前），我们可以看到集成的重演，就像在那个时间点发生的那样。使用

-c3

（分支机构的变更列表），我们看到“所有修订都已集成”，因为到那时它已经发生了。

在继续尝试所有参数组合后，我终于找到了适合我的解决方案：

p4 interchanges -b SOURCE_to_TARGET //depot/targetbranch/...@targetchange

将打印出源分支上缺少的所有更改targetbranch@targetchange. 它将只返回比targetchange早的更改。如果此列表不包含比sourcechange更早的更改，则targetchange是完整集成

当返回的列表很长时，该命令可能需要相当长的时间才能完成。不幸的是，我找不到截断搜索的方法，但我可以接受

---

看起来，服务器版本2018.2之前的一些功能有问题，这可能会在我之前的尝试中造成困难。

我不太明白这是如何工作的。据我所知，“p4集成”会影响当前工作区设置提交集成的所有内容。它将如何为这个“假设”集成设置工作区？无论如何，我发现自己的解决方案对我来说很好。感谢您的努力。对不起，我应该明确表示，我们的想法是使用

-n

来做报告/预览，而不是实际打开文件并提交集成（因为您尝试做报告，而不是实际集成某些内容）。这本质上是一个模拟，如果有人在提交变更123499后立即运行集成，将会发生什么。如果它报告“最新”，那么在那个时间点（这就是你要问的问题）所有事情都是最新的。如果没有，就没有。事实上，它确实有效。结果与我自己的方法相似，只是在一些特殊情况下，当“p4交换”声明所有更改都已集成时，“p4集成-C”有时会声明缺少集成。仅检查两个示例案例，我发现每个解决方案在一种情况下都是错误的。难看，但我没有时间再深入下去了。在我的例子中，误报更严重，因此我必须采用“p4 integrate-C”方法。到目前为止，我可以确认存在误报：在许多情况下，在创建新的完整分支的点，“p4 integrate-n-C”报告在分支点之前创建和删除的文件缺少集成。这些文件根本不会正确地显示在新分支上，但“p4 integ-n-C”仍将这些集成报告为挂起。更多误报：对于在原始分支上添加的文件，然后正确地分支到目标分支，然后在目标分支上删除的文件，“add”在分支点上显示为缺少集成。不幸的是，我们的历史上有超过10000个积分点，对于超过1000个积分点，“p4 integ-n-C”给出了可疑的结果。深入到几个单独的案例中，每一个都以某种方式与已删除的文件相关。我很确定这实际上不起作用-

@targetchange

arg正在应用于集成的源。我的猜测是，您有一个特定的测试用例，其中该技术恰好返回正确的结果（即，如果源和目标的更改足够接近，它在大多数情况下都会“工作”），但在一般情况下它不会做正确的事情。到目前为止，在项目的漫长历史中，该命令适用于大量示例案例。@targetchange参数肯定应用于集成的目标。据我观察，交换的文档（在服务器版本2019.1中）实际上是正确的：变体1（不带-b）应用了re