"Generating list of changesets and updating work items" taking extraordinarily long

I'm having a problem with the "Generating list of changesets and updating work items" part of the Team Build taking an extremely long time even when there are very few changes in a build. In one build the step took over 2 hours before I cancelled the build, I've been waiting 30 minutes so far on the current build.

Any suggestions

Visual Studio Team System26

The first time a build completes successfully, it retrieves all of the workitems and changesets that have been created to date on the selected Team Project. Once a team build has completed successfully the first time, all subsequent runs of that team build will be faster and only contain the work items and changesets since the last successful build.

- Steve

I had the same experience the first several times I was building our largest solution. After the first successful build, the build server started only showing differences and things went much faster. That said, it did seem like it took an unusually large amount of time to find the 3000 or so changesets that went into the first build.

We are planning to modify this "feature" so that in V2 the first successful build is not associated with any changesets or work items, rather than being associated with everything that has happened up until that point. Subsequent builds will continue to be associated just with the changesets and work items since the last successful build.

Note that this issue will bite you a second time if you ever happen to delete all of the successful builds for a particular build type - the next successful build after this delete will again be associated with all of the changesets and work items up until that point. This feature will also be fixed in V2 (the last successful build will actually be store in the DB, rather than being calculated on the fly). For now, you'll have to just wait through that first build and then the experience should improve.

-Aaron

Aaron,

That change does sound useful. Interestingly, the issue was that although the RunTests property was set to false the AfterTests target was still being executed, this target contained a very long running task (execution of our NUnit test suites) and in the Visual Studio UI the "Generating list of changesets and updating work items" item was the one with the "green arrow" beside it.

William