When using the share extension some caches don't get copied over, incurring a potentially expensive cache recomputation. With O(3000) heads, the branchcache and friends can be costly. We should figure out a better strategy for sharing caches between shares, or at least copying over relevant caches.
Sound like related to https://www.mercurial-scm.org/wiki/AtomicRepositoryLayoutPlan
Bug was inactive for 151 days, archiving
I'm noticing this at Mozilla as we're starting to roll out aggressive use of auto pooled storage with shared clones. There is a delay of several seconds after the initial `hg pull` on a shared repo due to cache recreation. Someone please remind me to address this in the next release cycle if I forget :)
I noticed this again at Mozilla last week. We have an extension that streamlines the clone+share+updateprocess to make it so easy a caveman could do it. The process effectively stalls for ~10s between the share and update actions. The quick hack is copying certain cache files during hg.share() or hg.postshare(). IMO the better solution is to introduce a vfs instance rooted at the cache directory of the store and to switch caches to that vfs instance. That way, cache updates will benefit all repositories using that shared store.
Bug was inactive for 150 days, archiving
It has been fixed in 4.3 with https://www.mercurial-scm.org/repo/hg/rev/460733327640