这有点奇怪。这就是发生的事情。
因此，我们有一个VS2008项目，可以在perforce控制下输出到多个文件。这些文件设置了始终可写的标志。
我在VS中编译项目，它在我的机器上提供了最新的二进制文件。如果我然后通过perforce恢复这些二进制文件，我有perforce版本（即旧版本）。
尽管如此，此时再次编译项目检测不到任何更改，也不会重新制作这些二进制文件。在某种程度上，这是有道理的，因为没有任何代码或obj文件发生了变化，但它并不是我想要发生的事情。
我们的自动构建服务器出现了这种情况。我可以想到我可以做很多不同的小黑客来解决这个问题，但我想我可能会遗漏一些基本的东西。
实际的构建过程使用了虚幻的构建工具，因此幕后有一点魔力，我并不完全熟悉。
编辑：这是一个C / C ++项目，忘了提及。
答案 0 :(得分：3)
我只想补充一点，您观察到的行为是使用时间戳来确定文件是否已更新的结果。
当编译机和文件托管机器不同且时钟不同步时，您可以观察到类似的问题。
现代构建系统使用MD5标记而不是时间戳，这使得它们不受这些构建问题的影响。
答案 1 :(得分：2)
您是否已禁用modtime客户端选项（即设置为nomodtime）？如果该选项被禁用，Perforce将使用当前日期和时间同步所有文件（包括，我相信，您明确还原的文件），因此如果您的构建系统只是检查文件时间戳，它会认为二进制文件比源文件更新文件并声明自己完整。
（我倾向于故意禁用我的客户端中的modtime，这样当我同步源文件时，我的构建系统总是会重建受到潜在影响的二进制文件。）
答案 2 :(得分：0)
我遇到过与SVN类似的“问题”，所以这是大多数版本控制系统常见的事情：
当您更新或恢复或以任何方式修改版本控制下的文件时，它们通常会花费时间 - 就像使用触摸一样。所以，正如Commodore所提到的，你的二进制文件现在比其他任何东西都要新，所以它必须是最新的。
我在恢复源文件（尤其是头文件）方面有类似的经验，我不希望重建，因为我期望恢复像DOS COPY，但是因为有问题的文件可以使用现在，VS认为二进制文件已经过时并重建了依赖于源文件的所有内容。
它就是这样完成的，所以你永远不会得到像使用不同版本的头文件构建的库。
您可以尝试“触摸”关键文件（如常见的头文件）来强制重建，或者只是让Visual Studio进行完整的重建。
哦，并且不要在版本控制下放置构建输出的文件 - 您只需要源文件。您需要将二进制文件存储在其他位置，可能是在过时的文件夹中。