In pre-2.2 release, we maintained only one deployment report for each Staging area, which was overwritten upon each subsequent deployment.
Now, one reason why you may have this locking error is that another user may have concurrently issued a deployment request, and the first deployment
is still concluding and writing back to the deployment report file. Or, a previous deployment was interrupted writing back to the report file, and it
never released it's lock (on a side note, users can concurrently deploy; one the receiving side, however, all deployment requests stack up and serialize -
necessarily - so that we can guarantee consistent snapshots that corresond with Staging).
This should all go away with 2.2E, however - even in the case of the interrupted deployment. In 2.2E, we maintained a configurable number of
deployment reports per Staging sandbox; the default is 10,000. In this case, no deployment should ever attempt to write to the same file - and
so even if there's a lingering lock, that shouldn't be an issue for any subsequent request.
If also means you have some great audit trails. You can read more on the Deployment page on the wiki. This 2.2E feature will be rolled into the
next 2.9 Community build.
Kevin
