Author: JianJun Jiao
Editor: Suhas Kakkadasam Sridhara Yogin
LiveCycle Workbench ES2 can process conflicts in parallel development, but for better parallel development, we’d better know which operations will affect operations other developers perform.
In Workbench ES2, there are six operations on application assets and seven operations on applications which could affect each other when they are carried out in parallel.
Note: Operations in bold are specific for assets or applications.
Operations related to application assets are:
- Check in
- Check out
Operations related to applications are:
- Check in
- Check out
From an implementation perspective of these operations in LiveCycle ES2, they can be categorized into three groups by how much developers would affect each other when they carry out these operations.
- High: check out and delete
- Medium: check in, deploy, undeploy and invoke
- Low: revert and synchronize
Broadly, the types of operations that a developer carries on in Workbench ES2 can be categorized into three groups by the frequency of how often the developer performs them.
- Executed frequently: Check in, check out and synchronize. During development, these operations would be performed highly frequently.
- Executed occasionally: invoke, deploy, undeploy and synchronize.
- Executed rarely: delete and revert.
Among these operations, check-out is executed frequently and affects others highly. Workbench provides a “lock” to each application asset. Although the “lock” is not obvious to users, it makes Workbench support parallel development accordingly. When a developer checks out an asset, the developer gets the “lock”. After that, if another developer tries to check out the same asset, a warning dialog is shown “File is currently checked out by …”.
If the second developer selects to force check out the file, the second developer gets the “lock” but the first developer loses the “lock” because the “lock” is exclusive. After that, when the first developer tries to check in the file, a warning dialog will be prompted the operation failed and then the status of the asset is reset to check-in from check-out. If the first developer has made some changes to the assets, although check-in fails, the changes remain in the local copy of the file. Once you synchronize the file, the changes in local copy will be missing. So if you want to save the local copy, do it before you synchronize it.
Since the “force check-out” nullifies others’ “lock” on assets, it should seldom be used or used very carefully in an application if there are other developers working on the same application.
Generally, the operation deploy/undeploy is seldom carried out in design time but more often in debug time. The conflict happens when one deploys the application and the other undeploys it. The consequence is that only one operation can take effect. So, a secure way to check the deployment status is to synchronize the application.
The deletion of files is not used too often. Executing operations on an application asset which has been deleted from server by others is not a problem because it can detect that the asset does not exist on the server.
The “revert” and “synchronize” only affects the local copy of assets so such operations won’t affect others.
The operation “synchronize” is suggested to use often in parallel development. Thus, you can make sure the applications and application assets are in a synchronized state.
Once we understand how Workbench settles conflicts, we could use Workbench for better parallel development.