我们将TeamCity与subversion和MSBuild一起使用,我们遇到Subversion提交触发的连续构建问题.

设置连续构建以进行增量构建(每晚构建完整且干净).

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

为了更加清晰,这里是时间线：

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

现在问题是：

T9：构建服务器不会将file.cpp(T4)编译成file.obj,因为file.obj是T5,因此编译器认为它比源文件更新.

这个问题很容易通过完整版本修复,但这些问题需要很长时间(没有单元测试需要30分钟).

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

编辑：这个问题似乎只在使用服务器端签出模式时发生.使用构建代理程序端检出模式更改文件获取检索时间的时间戳,而在服务器端检出时,它们将提交时间作为时间戳.

最佳答案 是的,你肯定有竞争条件.我想你可以试着通过询问更改日志并触摸那里列出的任何文件来变得聪明 – 或者更好的是,如果它支持Subversion不保留文件修改时间,而是让文件的日期标记为它们的日期更新位置.

我在其中看到的其中一个问题是大多数时间只运行增量构建,但是有一部分构建运行干净(可能是每晚).你可能会定期陷入这种竞争状态,但你会定期突破它.根据这种情况发生的频率,这个kludge可能足够好.