退出更改列表后重新提交的正确工作流程是什么？

Question

在发现与另一个项目存在运行时冲突后，我最近不得不撤销提交的更改列表 (CL#926201)。

退出更改列表后，我使用（从我的工作区的根目录）同步到我之前提交的更改列表：

p4 sync ...@926201

这会将我已更改文件的旧版本下载到工作区，但没有将它们添加到待处理的更改列表中。

我希望将原始变更列表中的文件添加到新的变更列表中，以便在本地调查问题并进行必要的修改后重新提交。

我找不到任何可以为我完成此操作的命令，但我确实通过使用（从我的工作空间的根目录）协调了我的工作空间中未添加到我的工作空间中的任何更改列表中的已更改文件：

p4 reconcile

结果证明这是一个错误。该命令运行了大约一个小时，并最终从我曾经用完该工作区的每个项目的每个目标目录中添加了每个工件。我最终得到了一个 52,000 个文件的更改列表。 Perforce 尽职尽责地为我从 depot 中检查了所有这些文件，这需要一个小时左右才能撤消。

此时我决定仅手动将我在 CL#926201 中修改过的文件添加到新的更改列表中。这需要更长的时间，但我最终得到的一切都与最初提交 CL#926201 之前的情况相匹配。

万一我在这个过程中犯了错误，我决定再次与仓库同步，​​以确保差异正是我想要保留的差异。我为此使用了 IntelliJ，我假设它在内部调用了某种 p4 同步（我知道强制标志已关闭，因为在 IntelliJ GUI 中有一个选项）。我预计会有合并冲突（或任何 Perforce 所称的），这将使我能够简单地接受所有本地修订。不幸的是，我的新更改列表中的所有文件都立即恢复为回退修订版。我怀疑从以前检索特定修订版以某种方式将这些文件标记为“可以覆盖这些文件，因为它们很旧”。我不知道具体情况，但我很想知道。

现在我回到了第一阶段，我决定放弃直接使用 Perforce，并最终手动将所有文件差异逐行复制到现有类中，这样当我执行时它们看起来就像对 Perforce 的新更改最终去提交他们。这是一个乏味的过程，我觉得不得不这样做很愚蠢，但它最终奏效了。

现在我想知道我应该如何处理这件事。这似乎是一个相当常见的用例，但我找不到任何关于取回更改并在退出后重新提交更改的正确方法。我应该在这里做什么？

Answer 1

请记住，恢复已撤销的变更列表实际上只是撤销变更列表的另一种情况（您正在撤销撤销），所以我要说的一切都与一般撤销变更列表有关，而不是“重新提交”特别是已退出的更改列表。 :)

如果您的目标是将当前目录下的所有内容恢复到更改 926201 时的状态，这里有一个非常简单的选项：

p4 copy ...@926201 ...

这将打开文件，因此您可以在提交之前查看生成的更改列表/差异/等。

如果您要使用 reconcile 来执行此操作，则步骤顺序将更像：

p4 sync ...@926201
p4 sync -k ...
p4 reconcile ...

诀窍在于，即使工作区的实际内容是@926201，您也想告诉服务器您正在对与 head 修订相关的文件进行操作——这就是“sync -k”的用武之地（在保持物理工作空间内容的同时将 have rev 增加到 head rev）。

有关“p4 复制”和“p4 协调”之前的更复杂变体，请参阅这篇 Perforce 知识库文章：http://answers.perforce.com/articles/KB/3474/?q=backout+a+changelist&l=en_US&fs=RelatedArticle

根据您对从 IntelliJ 执行“同步”的描述，听起来可能在幕后涉及“还原”——一旦使用“p4 编辑”或“p4 协调”打开文件，“p4 同步” " 绝对不会碰它，即使使用了 "-f" 选项。最多它会安排一个“p4 解析”（然后根据选择的解析选项更新/覆盖/合并/保留内容）。