Manage updates of a collaborative project
Updating a collaborative project consists in retrieving and posting components of a test project between the collaboration server and the local machines. In some situations, managing potentially conflicting updates proves necessary. NeoLoad 8.2 provides all the information to help identify collaborative issues and solve them.
The Collaboration module relies on the following graphic charter.
| Icon | Action | Example |
|---|---|---|
| Green arrow | From the local machine to the collaboration server |
|
| Blue arrow | From the collaboration server to the local machine |
|
| Red arrow | Conflict between the collaboration server and the local machine |
|
The following sub-icons tell the status of an item in a collaborative project.
| Icon | Action | Example |
|---|---|---|
 |
Publish item onto the collaboration server |
|
 |
Modify item on collaboration server |
|
 |
Delete item on collaboration server |
|
 |
Add the item locally |
|
 |
Modify the item locally |
|
 |
Delete the item locally |
|
 |
Content conflict with the item |
|
 |
Item in tree conflict deleted on collaboration server |
|
 |
Item in tree conflict added onto collaboration server |
|
|
Item in hidden conflict |
|
Updates with no conflict
In a situation where locally modified elements are not updated, there is no collide risk. Elements are always updated from the server to the local machine.
In the Update Project wizard, these elements are represented with a blue left-oriented arrow.
| Example | Meaning |
|---|---|
|
Blue arrow with a + (plus) sign: The VirtualUser_3 VU is going to be added locally. |
|
Blue arrow: The delay delay is going to be modified locally.
|
|
Blue arrow with a – (minus) sign: The visit Container is going to be deleted locally.
|
Updates with content conflicts
When Member 1 and Member 2 modify the same element at the same time, a content conflict occurs.
If Member 2 has published the changes before Member 1 and if both of them have used the same version of the element, NeoLoad tells Member 1 that the element carries a conflict on updating it. Three resolution modes for the conflict are available:
-
Try to merge: The changes made by Member 1 and Member 2 are merged.
-
Keep mine: The changes made by Member 2 are ignored and the changes made by Member 1 are kept.
-
Take from repository: The changes made by Member 1 are ignored and the changes made by Member 2 are kept.
Note: NeoLoad may fail to merge Member 1 and Member 2 changes when the changes involve the data of a very same element. It is necessary to choose one of the two other resolution modes, i.e. sustaining the local changes (Keep mine) or retrieving the remote ones (Take from repository).
In the Update Project wizard, a red tag stands for a content conflict. The name of the element involved is followed by the selected resolution mode.
| Example | Meaning |
|---|---|
|
Double red arrow: The VirtualUser component is in a content conflict situation |
When a content conflict is detected, the wizard displays the Conflicts Resolution screen.
The resolution mode options for the conflict are:
-
Try to merge: NeoLoad 8.2 tries to merge the content of the local component with the component already on the collaboration server.
-
Keep mine: The local component is used for the project.
-
Take from repository: The collaboration server component is used to update the project.
Click Next to validate the selection or it may display the Failed Merge Resolution screen.
When one or more Try to Merge resolution actions have failed, it is necessary to choose the Keep mine resolution option or the Take from repository one.
Note: The Go to previous conflict and Go to next conflict buttons, in the upper right part of the conflicts resolution area, help navigate easily among conflicts.
Updates with tree conflicts
When one of the two team members has ignored the element itself whereas the other members have modified it, an element tree conflict is identified.
This may occur in the following situations: Deleting, renaming, or moving the element or its hierarchy. It may also happen when Member 1 and Member 2 have both modified the element tree or hierarchy, or when only one of them has updated the recorded content of a shared Virtual User, as described in Update recorded content. Two resolution modes are available in NeoLoad to process a tree conflict. If Member 1 has made the update, the wizard suggests the following actions:
-
Keep mine: The changes made by Member 2 are ignored and the changes made by Member 1 are kept.
-
Take from repository: The changes made by Member 1 are ignored and the changes made by Member 2 are kept.
Note: NeoLoad also makes it possible to take no decision. Team members can then work together to understand the conflict reasons.
In the Update Project wizard, a red tag with an icon represents a tree conflict. The name of the element involved is followed by the selected resolution mode.
| Example | Meaning |
|---|---|
|
Double red arrow with a – (minus) sign: The VirtualUser_3 Virtual User is in a tree conflict situation. It has been deleted on the server |
|
Double red arrow with a + (plus) sign: The VirtualUser_3 Virtual User is in a tree conflict situation. It has been added onto the server.
|
When a tree conflict is detected, the wizard displays the Conflicts Resolution screen.
The resolution mode options for the conflict are:
-
Keep mine: The local component is used to update the project.
-
Take from repository: The collaboration server component is used to update the project.
Note: Only Virtual Users can be selected in a tree conflict situation, whereas all the elements can be selected in a content conflict situation. Resolution actions must be undertaken at the Virtual User level for a tree conflict.
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.
Note: 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.