Is incremental building possible in combination with Continuous Integration?

We use TeamCity with subversion and MSBuild and we have a problem with the continuous build that is triggered by Subversion commits.

The continuous build is set-up to do incremental builds (the nightly build is full and clean).

The problem occurs if a developer changes and commits file for the second time after the build has started (commit triggered) but before the object that uses the file is built. Now the object file gets a timestamp that is after the timestamp of the second commit. This will cause all later incremental builds to skip the changes to the file.

For extra clarity here is the time line:

T1: Developer commits file.cpp (file.cpp has time T开发者_运维技巧1)

T2: First incremental build starts on the build server

T3: Build server gets the files for the latest change (file.cpp at T1)

T4: Developer commits file.cpp for the second time (file.cpp has T4)

T5: Buildserver compiles file.cpp of T1 into file.obj (now file.obj has time T5)

T6: First Build finishes (result is good)

T7: Second incremental build starts on the build server

T8: Build server gets the files for the latest change (file.cpp at T4)

And now the problem:

T9: Build server doesn't compile file.cpp (of T4) into file.obj because file.obj is of T5 hence the compiler thinks it is newer than the source file.

The problem is easily fixed with a full build but those take a long time (30 minutes without unit tests).

Is incremental building possible in combination with Continuous Integration?

Edit: This problem only seems to happen when using server side checkout mode. With build agent side checkout mode changed files get the timestamp of the time of retrieval while with server side checkout they get the commit time as timestamp.

Yes, you definitely have a race condition. I suppose you could try to get clever by interrogating the change log, and touching any files listed in there - or better yet, if it's supported have Subversion not preserve file modification times, rather have the date stamp of the files be the date they were updated located.

One of the kludges I've seen around this is to only run incremental builds most of the time, but have some fraction of the builds run a clean (perhaps nightly). You might get caught in this race condition periodically, but you'll break out of it on a regular basis. Depending on how frequently this occurs, this kludge may be good enough.