Let me set the scenario. I have an svn repository. In fact, I have many. They are interlinked via svn:externals. They have tight dependencies between them, and we often commit to both of them at the same time.

At 1:58pm, we had a commit go through on a repository. We'll call it apple-r155, made to the file:
svn://svn/apple/trunk/main.cpp

At 2:00pm, Bamboo polled the repository and scheduled a build (#6). The agent was busy so the job was queued.

At svn://svn/apple/trunk, svn:externals is defined to be:
svn://svn/banana/trunk banana
(we actually use this notation, which means the same...)
^/../banana/trunk banana

And at 2:10pm, another commit happened to banana, banana-r97, but to:
svn://svn/banana/trunk/foo.cpp

And another at 2:15pm, commit banana-r98, to:
svn://svn/banana/trunk/bar.cpp
(this isn't a necessary step to reproduce the problem, but it actually happened in our scenario at the time)

Finally, at 2:20pm, the agent became free to run, but it didn't notice at this time other changes to the repository. The log said that it was updating to revision apple-r155. It updated based on the revision number. But "svn up -r155" doesn't pass any meaning of banana's revision. The update step actually also pulled banana-r98, not banana-r96, but it didn't report to the build the changes that came with banana-r97 or banana-r98.

Once this job was done, it polled the repo again and found it should run another build (#7), to take in banana-r97 and banana-r98. This build did report the changes of banana-r97-98, but the actual build didn't reflect those changes. Instead, build #6 was actually reflecting those changes.

The fix here, is that bamboo should do one of two things, contrary to what it currently does.

1) Every build should run "svn up --ignore-externals -r

. banana"
... where the "2015-02-12 14:00:00" represents the time the svn repositories were checked. "banana" represents all externals.

What this would do would be to ensure that only the changes polled for are the ones run during the build. This is only important for a job that is queued, where other commits might happen during the queuing of the job. If other changes happen while the job is in queue, then latter poll will account for those.

2) If build is queued for a time, the svn-poll should re-check for changes at the time of the actual update, and report all changes during the queuing to be part of the build that happened, such that the final result of build #6 (in the above scenario) would show 3 changes. Using this means, build #7 would not have happened.

This is effectively calling the queuing time effectively the same as the quiet period, I think. That approach is fine with me.