A conflict can occur if two or more users make changes to the same fields in the same objects and this results in the fields being set to different values.
Conflicts can only occur when getting other users' changes when another user has already committed a different change to the same data. Bear in mind that getting other users' changes is the first stage in committing your own changes back to the database, so conflicts will often occur as part of this process.
Commit changes regularly to reduce the possibility of conflicts and to keep other users up-to-date. You cannot save your own changes to the database until you have successfully updated your local copy of the data with changes made by others, and resolved any conflicts that might arise. This means you have to choose to keep your own change, or discard it in favour of the change made by another user.
Conflicts can be difficult to resolve. Within InfoAsset Manager the process of choosing one value or another is relatively simple. However, within your organisation there will probably be phone-calls, e-mails and even meetings to decide why the conflict has arisen and which value is correct.
The best approach is to plan your work to minimise the chances of conflicts ever occurring:
- Update your local version controlled database items by getting the latest changes made by others from the server before starting to make changes yourself.
- Commit your changes frequently.
- Make sure two members of the team are not trying to do the same task.
How to Resolve Conflicts
If conflicts occur when you get other users' changes, your local database will be updated and you will see a message showing you how many objects have conflicts.
Example of warning message displayed when there are conflicts
- Click OK and you will see the Resolve Update Conflicts dialog. This dialog displays the conflicts for one object. You can scroll through the list of objects with conflicts and resolve conflicts for each object in turn. The object you are currently resolving is highlighted on the Grid Windows and GeoPlan.
- The buttons along the top of the dialog allow you to work with all the conflicting objects:
- Use the Previous object and Next object buttons to scroll through the list of objects where conflicts have occurred.
- Use the Select all button to select all objects with conflicts.
- Use the Refresh button to update the count of objects with conflicts. You will need to do this periodically to keep track of how many objects remain with conflicts.
- The Commit button can be used when ALL conflicts have been resolved. If you do not resolve everything, the commit operation will fail and you will find yourself back at this dialog.
- All the information below the line represents the conflicts in the current object:
- Each row on the grid is a single conflict.
- The Keep your change checkbox in the right hand column allows you to keep your change or discard it in favour of the Latest Value currently in the database.
- The value coloured green is the one that will be used if you click the Resolve conflict button. Which value is coloured green depends on the Keep your change checkbox.
- Use the Delete my object button if you have created a new object with the same ID as one created by another user, and you want to keep the other user's object and not yours.
- Use the Edit object button to display the object's property sheet. You can make any changes you want. If you need to rename an object because of a duplicate ID you will have to do this via the property sheet.
- Use the Find button to select and zoom in on the current object.
- Use the Commit history button to open the Commit History dialog for the network object currently selected in the Resolve Update Conflicts dialog. In the Commit History dialog, you can view details of any previous commit, view differences between two versions as well as copy history to the clipboard. In particular, you can see the name of the user you are conflicting with. This information can be useful for resolving conflicts efficiently and rapidly.
- Each row on the grid is a single conflict.
- When you are happy that the selections you have made to resolve all the conflicts for the current object, click the Resolve conflict button. This will apply the chosen values, mark the object as resolved, and move on automatically to the next object with conflicts.
- Once you have resolved all outstanding conflicts, you can click the Commit button. This will display the Commit Changes dialog and take you into the Committing Your Changes process.
Objects with the Same ID
If you have created (or renamed) an object so it has the same ID as an object added by another user you have three options:
- rename your object. You must do this if you want to keep both objects. Click Edit object to display the object's property sheet and change the name there.
- discard your object. Click the Delete my object button
- merge the two objects. You can merge the two objects together by resolving all the individual conflicts between them.
Conflicts Involving Array Data
Some data , for example line or boundary geometry, is stored within the database as arrays. When a conflict exists in this array data, the Resolve Update Conflicts dialog will show that there is a conflict, but it will not show which values differ. This is because of the way this array information is stored.
Example Scenarios
Here are some examples of possible conflicts and how they are dealt with by InfoAsset Manager. These examples may not come from your specific Innovyze software but the same principles apply.
The network contains a manhole with ID 'M101' and the System Type field set to other. Two users User 1 and User 2 both download the latest version of the network.
Click on the images below to reveal the examples.
Example1
User 1 changes the System Type field on manhole 'M101' from other to foul
User 2 notices, whilst making other changes, that manhole 'M101' does not have the correct System Type so changes the field from other to combined
User 1 commits changes to the server. The network now has foul in the System Type field for manhole 'M101'
User 2 attempts to commit changes to the server. InfoAsset Manager first tries to update User 2's local network with User 1's changes. InfoAsset Manager detects a conflict and the commit is rejected. User 2 must resolve the conflict before trying another commit. InfoAsset Manager informs User 2 of the problem with the System Type field. User 2 must choose to either keep his change or User 1's. Obviously either User 1 or User 2 has made a mistake and User 2 should find out which is the correct System Type for this manhole – or perhaps to set it back to other.
Example2
User 1 changes the System Type field on manhole 'M101' from other to combined
User 2 notices, whilst making other changes, that manhole 'M101' does not have the correct System Type so changes the field from other to combined
User 1 commits his change to the server. The network now has combined in the System Type field for manhole 'M101'
User 2 updates his local copy of the network, possibly as part of the commit process. The update succeeds because although User 1 has also changed the same data field the InfoAsset Manager detects they made the same change so there is no conflict.
Example3
User 1 renames manhole 'M101' and calls it 'X101'
User 2 adds a new manhole and calls it 'X101'
User 1 commits his changes to the server. The network now has a manhole 'M101' renamed to 'X101'
User 2 commits his change to the server. InfoAsset Manager detects a conflict and the commit is rejected. User 2 is informed that there is already a manhole 'X101'. User 2 must resolve this conflict by renaming his new manhole.
Example4
User 1 renames manhole 'M101' and calls it 'X101'
User 2 renames manhole 'M102' and calls it 'X101'
User 1 commits his changes to the server. The network now has a manhole 'M101' renamed to 'X101'
User 2 commits his change to the server. InfoAsset Manager detects a conflict and the commit is rejected. User 2 is informed that there is already a manhole 'X101'. User 2 must resolve this conflict by renaming manhole 'M102' to another name, accepting the name 'X101' or reverting to the old name 'M102'.
Example5
User 1 deletes manhole 'M101'
User 2 changes the System Type field on manhole 'M101' from other to combined
User 1 commits his changes to the server. The network no longer has a manhole called 'M101'
User 2 commits his change to the server. InfoAsset Manager detects manhole 'M101' has been deleted and does not apply the edit.