在对我们的perforce仓库的历史进行分析时,我需要确定执行了另一个分支的完整集成的那些更改,并找出该集成源的确切更改编号。不幸的是,尽管这种全面的集成是一种常见的操作,但我在历史上找不到任何简单可靠的方法来检测它。如果我错过了什么,请告诉我。
无论如何:通过使用“ p4 filelog”并匹配修订号的一组脚本,我设法找到了所有候选变更及其各自的集成源变更。我所缺少的是一种将完全集成与只限于子目录的cherry-pick或部分集成区分开的方法。为此,我能找到的最接近的命令是“ p4交换”命令,它完全满足了我的需要,除了“ toFile”参数不能具有“ @”修订规范的问题。
我希望
p4 interchanges //depot/sourcebranch@123400 //depot/targetbranch@123499
会告诉我在我发现的集成点中是否缺少任何更改,但是只会给出错误“此处不能使用修订规范(#或@)”。 -与文档匹配。
是否还有其他方法可以检查p4历史记录中的积分点,以区分出完全合并中的樱桃派?
答案 0 :(得分:0)
使用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的错误修复未显示在相关说明中...)
这是一个将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.
使用-C 2
(在分支之前),我们看到了集成的重播,因为该集成将在该时间点发生。使用-C 3
(分支的变更列表),我们看到“所有修订都已集成”,因为到那时为止,它已经发生了。
答案 1 :(得分:0)
在继续尝试所有参数组合后,我终于找到了一个适合我的解决方案:
p4 interchanges -b SOURCE_to_TARGET //depot/targetbranch/...@targetchange
将打印出源分支上targetbranch @ targetchange上缺少的所有更改。它将仅返回早于targetchange的更改。如果此列表不包含早于sourcechange的更改,则targetchange是完全集成。
当返回的列表很长时,该命令可能需要花费大量时间才能完成。不幸的是,我找不到截断此搜索的方法,但我可以接受。
看来,某些功能在服务器版本2018.2之前是错误的,这可能在我的早期尝试中造成了困难。