These jobs do not actually share workspaces, to be accurate. They each have their own workspace, but within the same working copy of the repository. That is because we have one big repository for our entire suite of software. Inside that repo we have different sections for our different modules that belong to this suite (i.e. - Foundation, Picking, Sorting, Planning, etc). The base URL for the source for these is GII/All/trunk/30-Dev, so my workspaces are at /30-Dev/Foundation, /30-Dev/Picking, /30-Dev/Sorting, etc... So even though I may only be updating the portion of the working copy at 30-Dev/Picking, SVN locks the working copy up at 30-Dev. Thus, I cannot update 30-Dev/Sorting while my Picking job is updating. There are interdependencies between the aforementioned modules (primarily on Foundation) that would make it difficult to break away from a shared working copy. Basically, this repository was designed to simplify developers lives.
Yes, this is less than ideal (I would love to have individual repositories as we did in Gen 1 of our software), but we are dealing with the constraints given to us. It presents some challenges in a build environment, but the head architect decided to go this direction as it makes a ton of sense for the application side of the business who are actually customizing our product and implementing it for our customers. It may appear to lack sense to someone from the outside looking in with no knowledge of our business model, but it's the hand we've been dealt.
Throttle Concurrent Builds Plugin really does not provide what I'm after, any more than what I could achieve with limiting executors, though it would simplify that approach. That would queue up my other jobs, which is counter-productive to fast feedback for builds triggered by commits. I don't want to throttle at the job level. I simply want the ability to wait during the svn update portion of these jobs.
We may look at building our own custom plugin for svn updates if this does not make sense to the core community. I would like to have a plugin that is flexible enough to deal with our business constraints, but if that can't happen then I suppose it's time to start creating our own.
As I wrote in JENKINS-17228:
Hence IMO this request does not make any sense, as it does not appear to be a sensible use case.