在强制恢复后，Visual Studio 未检测到 exe 已过期
这是一个有点奇怪的情况。这就是发生的事情。
因此，我们有一个 VS2008 项目，它在 perforce 控制下输出到许多文件。这些文件设置了始终可写标志。
我在 VS 中编译该项目，这为我的机器上提供了最新的二进制文件。如果我随后通过 perforce 恢复这些二进制文件，我将拥有 perforce 上的二进制文件版本（即旧版本）。
尽管如此，此时再次编译项目不会检测到任何更改，也不会重新制作这些二进制文件。在某种程度上，这是有道理的，因为代码或 obj 文件都没有改变，但这并不是我真正想要发生的事情。
这出现在我们的自动化构建服务器的边缘情况下。我可以想到很多不同的小技巧来解决这个问题，但我认为我可能会在这里遗漏一些基本的东西。
实际的构建过程使用 Unreal 构建工具，因此幕后发生了一些我也不完全熟悉的魔法。
编辑：这是一个 C/C++ 项目，忘了提及。
This is a bit of an odd situation. Here's what's happening.
So, we have a VS2008 project which outputs to a number of files under perforce control. These files have the always writable flag set.
I compile the project in VS, which gives me up to date binaries on my machine. If I then revert those binaries via perforce, I have the version of the binaries that were up on perforce (ie, old ones.)
Despite this, compiling the project again at this point detects no changes and will not remake those binaries. In a way, this makes sense, since none of the code or obj files have changed, but it's not really what I want to happen.
This comes up in an edge case on our automated build server. I can think of tons of different little hacks I could do to fix this, but I'm thinking I could be missing something fundamental here.
The actual build process uses the Unreal build tool, so there is a bit of magic going on behind the scenes that I'm not entirely familiar with too.
Edit: This is a C/C++ project, forgot to mention that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我只是想补充一点，您观察到的行为是使用时间戳来确定文件是否已更新的结果。
当编译机和文件托管机不同并且它们的时钟不同步时，您可以观察到类似的问题。
现代构建系统使用 MD5 标记而不是时间戳，这使得它们不受这些构建问题的影响。
I just wanted to add that the behavior you observe is a consequence of using timestamps to determine whether a file was updated or not.
You can observe similar issues when the compiling machine and the file hosting machine are distinct and their clocks get out of sync.
Modern build systems use MD5 stamps instead of timestamps, which makes them impervious to these build issues.
您是否禁用了
modtime客户端选项（即设置为nomodtime）？如果禁用该选项，Perforce 将使用当前日期和时间同步所有文件（我相信包括您明确还原的文件），因此如果您的构建系统只是检查文件时间戳，它将认为二进制文件比源文件更新文件并声明自身完整。（我倾向于故意在客户端中禁用
modtime，这样当我同步源文件时，我的构建系统总是会重建可能受影响的二进制文件。）Do you have the
modtimeclient option disabled (that is, set tonomodtime)? If the option is disabled, Perforce will sync all files using the current date and time (including, I believe, files you explicitly revert), so if your build system is simply checking file timestamps, it will believe the binary is newer than the source files and declare itself complete.(I tend to intentionally disable
modtimein my clients, so that when I sync source files my build system always rebuilds potentially-affected binaries.)我在 SVN 中遇到过类似的“问题”，所以这是大多数版本控制系统的常见问题：
当您更新或恢复或以任何方式修改版本控制下的文件时，它们通常会占用时间 - 就像使用触摸。因此，正如 Commodore 提到的，您的二进制文件现在比其他任何文件都更新，因此它“必须”是最新的。
我在恢复源文件（尤其是头文件）时也有过类似的经历，并且我不期望重建，因为我期望恢复像 DOS COPY 一样，但是因为有问题的文件现在需要时间，VS 认为二进制文件已过时，并重建依赖于源文件的所有内容。
它是这样完成的，这样你就永远不会得到像使用不同版本的标头构建的库之类的东西。
您可以尝试“触摸”关键文件（例如通用头文件）来强制重建，或者只是要求 Visual Studio 进行完整重建。
哦，不要将构建的输出文件置于版本控制之下 - 您只需要源文件。您需要将二进制文件存储在其他地方，可能是在过时的文件夹中。
I've come across similar 'problems' with SVN, so this is something which is common to most version control systems:
When you update or revert or in any way modify files under version control, they generally take on the time now - just like using touch. So, as Commodore mentioned, your binary file is now newer than anything else, so it 'must' be up to date.
I've had a similar experience when reverting a source file (especially a header file) and I'd not expected a rebuild because I was expecting a revert to be like a DOS COPY, but because the file in question takes on the time now, VS thinks the binaries are out of date and rebuilds everything that depends on the source file.
Its done like this so that you never get things like libraries built with different versions of headers.
You could try 'touching' a crucial file (like a common header file) to force a rebuild, or just ask Visual Studio to do a complete rebuild.
Oh, and don't put files that are the output of a build under version control - you only need the source files. You need to store your binaries elsewhere, maybe in dated folders.