Perforce 索赔文件在不同时会有所不同

Posted 2023-02-19

【中文标题】Perforce 索赔文件在不同时会有所不同

【英文标题】：Perforce claims file is different when it's not

【发布时间】：2018-09-22 21:40:35

【问题描述】：

我的这个文件似乎进入了一个奇怪的状态。 Perforce 声称它已被修改且未打开：

> p4 diff -se
data.xml

通常，当文件被修改和未打开时，我可以使用sync -f 来修复它。但是，出于某种原因，这个特定的文件真的很顽固：

> p4 sync -f data.xml
//Depot/Stream/data.xml#19 - refreshing data.xml

> p4 diff -se
data.xml

与sync -f 一样，clean 似乎可以工作，但它仍然声称它已被修改：

> p4 clean data.xml
//Depot/Stream/data.xml#19 - refreshing data.xml

> p4 diff -se
data.xml

不出所料，当我尝试reconcile -w 时也会发生同样的事情：

> p4 reconcile -w data.xml
//Depot/Stream/data.xml#19 - refreshing data.xml

> p4 diff -se
data.xml

如果我使用reconcile（不带-w），文件会打开，但即使不忽略空格或行尾，P4Merge 也会将文件显示为相同：

> p4 reconcile data.xml
//Depot/Stream/data.xml#19 - opened for edit

> p4 diff -se

> p4 diff -sa
data.xml

使用revert 只是将其恢复到之前的状态：

> p4 revert data.xml
//Depot/Stream/data.xml#19 - was edit, reverted

> p4 diff -sa

> p4 diff -se
data.xml

什么给了？我之前已经复制了这个文件，但没有先打开它进行编辑。这是否使它进入了不可逆转的状态，也许与 Windows 权限有关？

我尝试删除文件 (del data.xml) 并重新获取它，但由 Perforce 创建的新副本有同样的问题。

【参考方案1】：

想到两种可能性：

服务器的文件校验和与其内容不匹配（这意味着差异将始终显示为不同）。您的管理员可以使用 p4 verify 命令进行检查。 文件中的行结尾不一致并且您有share LineEnd 选项，它实质上是在从本地磁盘读取每个文件时对每个文件进行隐式dos2unix 行结尾转换。如果dos2unix 是空操作，则文件将显示为相同；如果文件中有\rs，那么它们的删除将显示为差异。

在任何一种情况下，提交都可能通过创建一个带有与您工作区中的任何内容相匹配的校验和的修订来“修复”文件——但我建议让管理员检查p4 verify，因为如果文件已经坏了这可能是更大问题（磁盘故障等）的征兆。

【讨论】：

我提交了文件，问题就消失了。肯定是第二种情况，因为我确实有共享选项，而且它只影响了我。

您可以通过比较您提交的修订版与之前的修订版来检查这一点 - 您的修订版应该与之前的修订版相同减去一些 \r 字符（因此它应该显示为与 @987654328 相同@，但有不同的校验和和大小）。

【参考方案2】：

稍微详细说明@Samwise 的回答：

如果您的工作区配置了行结尾配置“共享”，但某个文件在某个时间点以 windows (CrLf) 行结尾签入到存储库中，则会发生这种情况：

当您获取文件时，perforce 会准确地将其拥有/跟踪的内容（文本文件，带有 windows 行结尾）保存到您的工作区，因为“共享”规定不进行同步时间转换。 如果您要保存文件，它会将行尾转换为 unix 行尾（有效地运行“dos2unix”作为提交的一部分）。 因此，当您运行“reconcile”（例如）时，它会将这些以 windows 行结尾的文件突出显示为“已在本地修改”，并邀请您打开它们进行编辑并提交。

这种情况大概出现在另一个用户，他们的工作区配置为“Unix”行结束模式，实际上提交了一个 Windows 样式的文件。因为配置“unix”根本不规定任何转换，所以“Cr”字符被保存在服务器上。这可能是偶然的，也可能是故意的。

在这种情况下正确的行动方案似乎有些不清楚：

您可以通过将行尾字符设置更改为“unix”而不是“shared”来“正确”地进行协调工作；但是，您可能会在以后不小心签入新的 CrLf 文件（假设您使用的是 Windows 并且您的某些工具倾向于这种方式），从而使每个人的情况变得更糟 - 就像之前的用户所做的那样 您可以真正将所有这些 CrLf 文件转换为 Lf（通过打开它们进行编辑并使用您的“共享”工作区设置将它们提交而不进行更改）以防止将来出现此问题，但这可能会显示为虚假更改许多文件。如果您的工具中的任何内容实际上依赖于这些包含 Cr 字符的文件，

也可能是错误的做法

- 例如，如果它们是针对某些测试过程的输出进行校验和的。

就个人而言，我将暂时将我的工作区设置从“共享”更改为“unix”，仅用于协调操作，然后切换回“共享”以用于日常 perforce 使用。