增量构建是否可以与持续集成相结合？

Question

我们将 TeamCity 与 subversion 和 MSBuild 结合使用，并且我们遇到了由 Subversion 提交触发的持续构建问题。

连续构建被设置为进行增量构建（夜间构建是完整且干净的）。

如果开发人员在构建开始后（提交触发）但在构建使用该文件的对象之前第二次更改并提交文件，则会出现此问题。现在，对象文件获得的时间戳位于第二次提交的时间戳之后。这将导致所有后续增量构建跳过对文件的更改。

为了更加清晰起见，这里是时间线：

T1：开发人员提交 file.cpp（file.cpp 的时间为 T1）
T2：第一次增量构建在构建服务器上开始
T3：构建服务器获取最新更改的文件（T1 处的 file.cpp）
T4：开发者第二次提交file.cpp（file.cpp有T4）
T5：Buildserver将T1的file.cpp编译成file.obj（现在file.obj有时间T5）
T6：第一次构建完成（结果良好）
T7：第二次增量构建在构建服务器上启动
T8：构建服务器获取最新更改的文件（T4 处的 file.cpp）

现在的问题：

T9：构建服务器不会将（T4 的）file.cpp 编译为 file.obj，因为file.obj 属于 T5，因此编译器认为它比源文件新。

通过完整构建可以轻松解决该问题，但需要很长时间（如果没有单元测试则需要 30 分钟）。

增量构建是否可以与持续集成相结合？

编辑：此问题似乎仅在使用服务器端结账模式时发生。使用构建代理端签出模式，更改的文件将获取检索时间的时间戳，而使用服务器端签出，它们将获取提交时间作为时间戳。

Answer 1

是的，你肯定有竞争条件。我想你可以尝试通过询问更改日志并触摸其中列出的任何文件来变得聪明 - 或者更好的是，如果支持 Subversion 不保留文件修改时间，而是让文件的日期戳是它们的日期已更新位于。

我在这方面看到的一个错误是大部分时间只运行增量构建，但有一部分构建运行干净（可能每晚）。您可能会定期陷入这种竞争状况，但您会定期摆脱这种状况。根据这种情况发生的频率，这种拼凑可能就足够了。