我有一个文件需要移动，该文件已经处于强制状态。移动后，需要进行一些编辑更新，以更新软件包，以适合其新位置。我应该提交移动changespec然后重新打开以进行编辑，还是可以一次性完成？如果是这样，适当的事件顺序是什么？

解决方案

提交移动更改，然后重新打开进行编辑(我们也可以使用重新打开选项)。
用户在更改历史记录中更容易阅读。

此外，最新版本的Perforce确实会在解析后执行文件更改检查。因此，在完成某些解决操作之后，可能会有投诉人在编辑文件。

我已经一口气做到了这一点，但是根据构建过程，我建议我们反对这样做。我通常这样做的是：

• 移动文件。
• 如果移动需要更改才能进行编译，请将其打开以进行编辑并进行更改。
• 提交更改，告诉perforce重新打开文件进行编辑。
• 对路径等进行更改，这些更改不会引起编译错误，但应进行更新。
• 提交这些更改并提供适当的描述。

但是，如果我们愿意，可以在上面的步骤(2)中进行所有更改。 Perforce可能会将新文件的标志从集成更改为添加，但仍会记住该文件的源路径。

编辑：更好的方法

我意识到我经常使用不同的方法，但是"移动"文件的想法分散了我的注意力。因此，我建议使用以下步骤：

• 将文件集成到新的路径/名称中，将先前的文件保留在那里。我假设这不会破坏构建过程。
• 提交新文件，提交后再次签出以进行编辑。
• 对新文件和项目进行必要的更改，以便我们使用新文件。
• 提交对新文件的编辑。
• [可选]我们可能需要检查分支规范，以查看是否需要将旧文件映射到任何分支中的新文件。
• 创建一个更改列表以删除旧文件，然后稍后再提交。

这种方法可以使编辑与重命名/移动完全分开，而永远不会使项目处于无法编译的状态。

另外，为什么还要等待步骤6？有时，尤其是在较大的项目中，我们可能想移动另一个人正在编辑的文件。 Perforce会很有帮助地告诉我们这一点。通过等待删除文件，我们可以让同事完成编辑并提交，而无需手动移动他们的工作。提交编辑后，可以将它们集成到新文件中，然后可以安全删除旧文件。

这里"安全"可能是重要的一点。重命名或者移动文件后，它将获得一个修订号" 1"，对于Perforce客户端来说，它看起来像一个新文件。当然，管理员可以获取其以前的历史记录，但是如果文件的编辑/版本历史记录对我们很重要，则获取旧版本会有些困难。

更新：感谢准将Jaeger和Greg Whitfield的启发。

即使是从Perforce支持下，要找到一个真正答案是什么也不容易，所以我想我会向每个人更新我们发现的内容：

• Perforce将每个文档的所有版本存储在其数据库中。
• 如果将文件保存为""或者""类型，则它将一个文件版本的差异存储到另一个文件中，而不是整个文件。
• 如果我们检出文件，则不对其进行任何更改，然后重新提交，该文件将另存为差异为0的新版本。这是可配置的，并且可以将P4设置为忽略变更列表项，而没有任何实际差异。我们可以通过在提交更改列表之前选择"还原未更改的文件..."来强制执行此操作。
• 使用"重命名/移动..."在P4中移动文件，以便它可以跟踪它们。不要使用Windows资源管理器复制它们，然后将其重新添加到P4中。
• 如果从上下文菜单中使用"重命名/移动..."功能，则"新"文件将显示修订号" 1"，就好像它是一个新文件一样。
• 但是，由于P4保存了对文件执行的所有功能，因此我们实际上可以使用CLI命令" p4 filelog -i"转到任何先前的版本(甚至恢复"已删除"的文件)。
• 如果我们不是移动管理员，而是想获取已移动或者重命名文件的修订历史记录，则可以右键单击并选择其"修订图"，其中显示了文件的每个版本，即使在分支之间移动时也是如此。

根据Perforce的支持，通过分支或者文件夹移动更容易地跟踪修订历史记录是经常需要的功能，并且在其当前路线图中。

Perforce的回答：目前，还没有一种方法可以移动/重命名/集成文件并仍然保持确切的文件历史记录。

但是，如果要通过右键单击要共享的文件夹来选择"集成..."，则新分支文件夹的文件和基础文件的版本将从版本1开始，但是集成历史记录分支文件夹和基础文件之间的关系以及原始文件夹和基础文件之间的关系仍将保留，我们可以通过它们来跟踪文件的修订历史记录。

是的你可以。只需重新打开以编辑分支文件(即新文件)即可。在P4Win中，有一个上下文菜单("重新打开以进行编辑")。

我会说总是先提交然后再编辑。它更加干净，使存储库中发生的事情更加明显。然后，只需在新位置签出文件并进行任何更改即可。这也使得更改在新位置中进行，并且在重命名后所有更改都可以使用的情况下更加明显。