Merge Algorithm

On issue or flush, changes made in an extract will be merged back to the parent extract.

The basic approach is that any changes made to the extract are applied to the parent extract, as shown below:

The granularity of this merge is at the attribute level, which means, two users can change different attributes on the same element and merge their changes together. If they modify the same attribute then a 'last back win' strategy is used.

AVEVA E3D Design makes sure that all merges are valid at the raw database level, so that, the data will be Database Integrity Checker (DICE) clean. However it is not possible to make sure that the data is consistent in engineering terms. Thus it is highly recommended that when variant data is flushed back, Data Consistency Checking Utility (DATACON) checks and Clasher checks are run on the resulting version.

The definition of the different sessions for issue and flush are:

The definition of the different sessions for refresh are:

The definition of the different sessions for drop are:

Note: The standard flush and issue commands also do a refresh. This makes sure that there is a suitable base session for the next extract operation.

The drop command compares the elements that are NOT to be dropped and applies the changes to create a new session.

The same algorithm is used for SAVEWORK and GETWORK.

There are two exceptions to the merge criteria as follows:

1. Once an element is deleted, then it stays deleted regardless of any conflicts in merging. For example, user 1 deletes /BOX, whereas user 2 changes an attribute of /BOX. If user 1 issues his change before user 2, then user 2's change will have no affect.

2. If the element type is changed, then the merge is done at the element level rather than the attribute level (that is, all the current attribute values are taken regardless of whether they have changed. Any attribute changes made by other users will thus be lost).