When used in a pipleine parallel block, the subversion plugin suffers from raceconditions due to the dependency on the "revision.txt" file as part of the checkout and change log computation process.

Unsynchronized access to "revision.txt" causes `SubversionChangeLogBuilder ` to fail spuriously, as the file may be written to concurrently by other running checkout processes.

The final "revision.txt" eventually reaches a stable state where it only contains the revision of the last "checkout" step, but in the process `SubversionChangeLogBuilder` has failed to record changes repeatedly (bailout with "No revision found for ....") and the "build.xml" is corrupted and contains fragments like the following:

    <org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState plugin="workflow-scm-step@2.9">
      <revisionStates>
        <entry>
          <string>svn http://redacted/trunk</string>
          <hudson.scm.SVNRevisionState plugin="subversion@2.12.1">
            <revisions>
              <entry>
                <string>ed/trunk</string>
                <long>16122</long>
              </entry>
              <entry>
                <string>svn http://redacted/trunk</string>
                <long>12362</long>
              </entry>
            </revisions>
          </hudson.scm.SVNRevisionState>
        </entry>
      </revisionStates>
    </org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState>

In summary:

• Unsafe reads from "revision.txt" which contains data from parallel checkout processes
• Lost writes to "revision.txt" from previous checkout steps in the same build, with unstable results

While producing "revision.txt" as a side product of the build process may be desired to keep as a side effect, using it internally means state between `SubversionSCM` instances in the same build is shared in an unsafe way. Assuming it is only written to once per build may be somewhat fitting to Freestyle projects, but is unsuited for pipeline projects.