Updates with hidden conflicts
A hidden conflict is a specific tree conflict. It occurs only when team Member 2 publishes an added element then its deletion before another team member retrieves it from the server. For NeoLoad, the element is unavailable on the collaboration server, but it can still cause a conflict raised by the update wizard if Member 1 publishes an element that is strictly identical.
When Member 2 publishes the deletion of an element, it leaves residual tracks which may collide with the Member 1 publication action of the same element (same name, same position in the design tree).
Solving a hidden conflict is easy still. The local version of the element—Member 1's—must be preserved to notify the collaboration server that the residual tracks of the previous element publication action—element—Member 2's—must be overwritten by the new local definition.
In the Update Project wizard, a single red arrow stands for a hidden conflict. The name of the element involved is followed by the selected resolution mode.
|
Example |
Meaning |
|---|---|
|
|
Simple red arrow: The VirtualUser VU is in hidden conflict. |
When a tree conflict of hidden type is detected, the wizard displays the Conflicts Resolution screen.
For a hidden conflict, there is only one resolution method:
- Keep mine: The wizard allows the team member to keep the local version to solve the conflict.
The residual tracks of the element on the server are deleted. The team member can publish the definition of the element without a conflict.
- Warning: When the hidden conflict is related to an element of the Virtual User, and not the whole Virtual User itself, the Virtual User is tagged as a tree conflict. The regular resolution modes for tree conflict are applicable. Solving the hidden conflict identified is applied to the whole Virtual User. If a team member retrieves the version—obsolete—from the server, the element in hidden conflict is deleted.