When the checkout DSL detects a parallel build it creates a clone workspace and a clone client definition. This might make sense for the use cases that create new workspaces, but it does not make sense when syncing to an existing statically defined workspace. This is especially problematic in the context of scripted pipelines where the developer is empowered to properly manage this situation via lock(), monitor(), etc.

Here is some additional color. Consider a multi-stage pipeline where the first stage does checkout and build, and archives build results such as images. Subsequent stages might do things like functional testing, Coverity analysis, etc. Since these are scripted we can insure that only the first stage actually uses the Perforce workspace. The pipeline mechanism allows stage 1 of the next job to run while stage 2 continues for the current one. This is a fundamental benefit of the pipeline. The current implementation results in this behavior:

• Creation of and population of a complete new workspace. For us this is several gigabytes (and well over an hour to compile - this is why we are incrementally syncing, after all). This needless work wastes disk space and Network IO - and it slows down my build.
• The need for me to 'manually' sync the workspace I actually use.
• The unused workspace is the deleted when the job completes

The automatic workspace cloning also results in disjoint change lists unless the user takes special actions to manage the sync variable. This all seems pretty awful to me.

There is, however, a workaround:

Change the workspace list identifier to workaround clone workspace issue

See:   https://issues.jenkins-ci.org/browse/JENKINS-11519

• Edit jenkins startup file (e.g. /etc/sysconfg/jenkins) to add:
  -Dhudson.slaves.WorkspaceList=_

With this the plugin does not try to create the clone since it is looking for the default '@' separator.