When creating a new changeset, you need to specify whether your changeset should be pessimistic or optimistic.
|
Pessimistic changesets are suitable for use when large amounts of new documentation are to be carried out, where the user is responsible for their own defined areas. Optimistic changesets are suitable for use in new project design and in situations where you want to develop and explore several different development proposals that all contain common network elements. |
Pessimistic
Working in a pessimistic changeset prevents other users who are also working in a pessimistic changeset from editing the same objects as you. In practice, this means that edited items that you have not yet posted to the database are locked for other users to edit. Users working in an optimistic changeset can edit the same object as the one with a pessimistic changeset, but not post the changes to the database.
All objects in the map view that are locked in this way can be visualized by choosing to display locked objects in a user-defined color. In addition, you can access information about the user and changeset that is currently locking an object and preventing you from editing it. This allows you to contact that user and ask them to make the item available again. The user who owns the changeset that is locking the item can choose to unlock or post the changeset to remove the item lock.
Optimistic
If you are working in an optimistic changeset, the items that you edit in the changeset are not locked to other users. Similarly, the items that are being edited by other users are not locked to you either. In practice, this means that several different users can edit the same object at the same time. Problems may arise if the same attributes of a component are edited in parallel in different changesets. In such a case, conflict management must be performed at the time of posting to determine which of the edited versions is valid and should be saved to the database.