Using the teamconcert plugin with Jenkins multi-configuration projects, there is a window (~1-3 minutes, depending how long it takes for the scm load and child builds to start) between when the "parent" build will accept incoming changes to the build work space, load the work space, reports the change set information in the parent build's "changes" interface, and when the "children" builds of the multi-configuration project start and do the same accept of incoming changes.

If someone delivers a change set in between the parent accepting, and any of the children builds accepting, the parent will not know that the child build accepted another change into the work space, but the change was actually there.

This makes it difficult for us to accurately know which build a change was in by looking at the parent build's 'changes' page (/job/continuous.dev/changes), more importantly, it can also mean that two 'child' builds will be building different content from each other.

Note that normally 'child' builds report no change sets in their 'changes' interface, except when this race condition occurs, and in that situation the child build that accepted the change set will report the change set information in it's own 'changes' interface (it will not appear in /job/continuous.dev/changes, but in, for example /job/continuous.dev/label_exp=ppc64le/changes).

Comparing our change set history in Jazz SCM to Jenkins, I see this happening approximately once per month for each stream we build, and it's particularly likely to happen when our Jenkins slaves are under heavy load.