A key consideration in a shared development environment is the locking behavior of the VCS Integration feature.

For example, Maria is logged on to one Integration Server, and Ashish is logged on to a different Integration Server. Both Integration Servers are connected to the same VCS server and both Maria and Ashish are responsible for development of the same webMethods package, which exists on both Integration Servers. If Maria checks out element FlowService1, it is marked as checked out on both Maria's Integration Server and the VCS server. Because the VCS Integration feature does not validate the state of the element with the VCS server until a VCS command is applied to it, Ashish's Integration Server knows nothing of this and shows FlowService1 as available. When Ashish attempts to check out FlowService1, he will receive a message stating that the file cannot be checked out. This behavior also applies to the Delete command, and to the move and rename actions.

The potential for locking conflicts within shared packages increases when the Check Out command is applied at the folder or package level. In this case, all of the supported elements in the package or folder are checked out (if they are not already checked out by someone else), thereby locking them from access by other users. To mitigate this situation, you are advised to check out only the files you want to modify, and avoid checking out packages or folders unless you are reasonably certain no other developers will need access to them.

If multiple users perform operations on an element concurrently, unexpected results might occur.