Problem Description:
My team is currently experienceing disk space issues on our master node from a multipipeline job.  We have a large mercurial repository set up that is cloning the repository each time instead of referencing the hgcached repository to read the Jenkinsfile.  Our repository is set up with many subrepositories that are being cloned from our server.  I expect that this might have something to do with it.  I see that the cached repository has all the recent reveisions, but is not updated to any of them, which might not trigger any of the subrepositories to be downloaded?

Each time a new branch is pushed in our repository, this triggers a new branch build in the multipipeline job (as expected).  To read the Jenkinsfile for that revision, a clone is made to the master/jobs/ folder (not expected).  I was expecting the Jenkinsfile to be able to be read from the cached repository instead of cloning the repo.  Am I understanding the "Repository Sharing" setting properly?

We have one master node and two slave machines set up.  On the two slave machines, a customWorkspace and disabledConcurrentBuilds is used to limit excessive cloning (unsure if this is the sanctioned approach, but it has been working so far).

Expected Behavior:
If "Repository Sharing" is being used, the Jenkinsfile could be read from the existing cached repository instead of cloning it again to the master's hard drive.

Data:
I have attached redacted copies of our Jenkinsfile, build log, and our OS/Jenkins/Plugin versions.