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

我们将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:生成服务器不将file.cpp（T4的）编译为file.obj，因为file.obj是T5的，因此编译器认为它比源文件新

使用完整的构建很容易解决这个问题，但是这些需要很长的时间（没有单元测试需要30分钟）

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

---

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

是的，你肯定有比赛条件。我想你可以试着通过询问变更日志，触摸其中列出的任何文件来变得聪明——或者更好的是，如果支持Subversion，那么就让Subversion不保留文件修改时间，而是让文件的日期戳成为文件更新的日期

---

我在这方面看到的一个难题是，大部分时间只运行增量构建，但让部分构建运行干净（可能是每晚）。你可能会周期性地陷入这种竞赛状态，但你会经常摆脱这种状态。根据这种情况发生的频率，这种混乱可能已经足够好了。

您的CI服务器可以询问您的VCS关于代码更改的情况。确实如此。问题在于时机。如果在CI服务器获得上一版本后更改了文件。版本，但在它实际用于构建之前，似乎有一个问题。@Halt:我的意思是，您的VCS可以告诉您真正更改了哪些文件，因此您可以触摸它们，以使构建系统正常工作。类似于

svn diff-r PREV:HEAD--summary | awk'{print$2}'| xargs touch

@J.F.塞巴斯蒂安：这是一个很好的建议，但为了使它起作用，TC必须让代理进行签出，而不是服务器，否则在构建代理上就没有可用的版本化签出。当我发现我的问题只发生在不使用代理端签出时。（见问题中我的编辑）。@Halt:1。您可以将构建拆分为两个任务，并将第一个更新时间戳的任务固定到CI服务器。或2。避免在构建过程中依赖时间戳（使用校验和，例如，

git svn

client免费提供的校验和；

make

也可以教你使用校验和）。我考虑过定期清理，但决定不这样做，因为问题发生后，如果它破坏了构建（这就是我们发现的原因）它将破坏以后的每个构建。如果它没有破坏构建，您就不能相信它会包含您的更改，因此在下一次清理之前，成功的测试将不会有多大意义。“如果它受支持，则Subversion不会保留文件修改时间，而是将文件的日期戳设为更新日期”这是Subversion的默认行为，除非在配置文件（）中显式设置“使用提交时间”选项