Much like JENKINS-48479 some kind of duplication also occurs when one build causes two updates of the @script directory and the workspace coming from the same repository, but the updates start from different revision (e.g. one from 10 to 15 and second from 12 to 15). Items contained in the change sets should be different then, but are the same.

It's easy to reproduce when there's only a single executor available. You need a Multibranch Pipeline configured with Jenkinsfile from SVN repository and a stage with checkout(scm) call in the file.

Reproduction steps

1. Start a build that will take a long time or pause it during the execution.
2. Start a second build that will update the @script directory and then stop to wait for an available executor.
3. Abort the second build, it will leave the @script directory updated, but the workspace at an older revision.
4. Let the first build finish or abort it.
5. Start a third build that will update the @script directory and then the workspace.
6. Both change sets available to the script will only have items that were updated during the @script directory update in step 5 despite updating from different revisions. In case the @script update from step 5 doesn't update anything, no change sets will be available whatsoever.

Remarks

• Using a separate SubversionSCM instance in checkout call doesn't change anything.