With "consistent versioning", nodes can be moved in both variant 1 and variant 2. How this works is explained in more detail here.

When moving nodes, the nodes that are not versioned are attached to the new object. There are neither predecessor nor successor versions, which is why the same node exists in two objects at the same time. The moved nodes get as OGUID the GUID of the new header and they keep as PREVOGUID the OGUID of the first version of the object. Therefore, the predecessor object can still be used, but not edited. 

Example

An example can be used to better understand the move in "consistent versioning": The following figure shows an object that consists of several children and children's children. Both variants of "consistent versioning" are shown. For variant 1, the header is versioned, and for variant 2, node C is versioned first, followed by node G of the successor version. The results are shown in the following figure.

Example step 1

Versioning in variant 1 is executed.

image-20240606-082455.png

Example step 2a

Next, node C version 1 is to be versioned under ROOT A version 2.

The object in its original form, before it is versioned:

image-20240606-082505.png

Example step 2b

Node C is to be versioned.

  • Node B version 1 is the parent node of node C version 1 and is released. Therefore, node B version 1 must be versioned.

    • Node A version 1 is the parent node of node B version 1 and is released. Therefore, node A version 1 must be versioned.

    • Thus, node A version 1 is the highest node below the ROOT that needs to be versioned.

    • Node A version 1 is versioned. To do this, the successor version, node A version 2, is added under ROOT version 2.

    • Node B version 1 is versioned. To do this, the successor version, node B version 2, is appended under node A version 2.

    • All necessary parents have been versioned.

    • Node C version 1 is versioned. To do this, the successor version, node C version 2, is appended under node B version 2.

    • The old subtree with the previous versions (node A version 1, node B version 1, and node C version 1) and its subnodes are still in the object.

    • The new subtree with the successor versions (node A version 2, node B version 2, and node C version 2) is also in the object.

    • Now it is known which node in the object has been versioned and which has not.

image-20240606-082516.png

Example step 2c

The unversioned nodes must be moved.

  1. The move starts from the highest node in the object, the node with the smallest hierarchy, which has been versioned: Node A Version 1.

  2. The algorithm goes horizontally through the object. This means that all nodes of a hierarchy level and hierarchy number are processed in groups.

  3. Hierarchy level 1: For node A version 1 is checked:

    1. Are there any direct child nodes of node A version 1 that have not been versioned?

    2. The answer is no.

    3. There are no other nodes in this hierarchy level 1 and hierarchy number.

    4. The next node is checked.

  4. Hierarchy level 2: For node B version 1 is checked:

    1. Are there direct child nodes of node B version 1 that have not been versioned?

    2. The answer is yes:

      1. The node F version 1. This node is attached to the successor of node B version 1, the node B version 2.

    3. There are no other nodes in this hierarchy level 2 and hierarchy number.

    4. The next node is checked.

  5. Hierarchy level 3: For node F version 1, the following is checked:

    1. Are there direct child nodes of node F version 1 that have not been versioned?

    2. The answer is yes:

      1. The node G version 1. This node is attached to the successor of node F version 1, the node F version 1 (not 2).

      2. The node H version 1. This node is attached to the successor of node F version 1, node F version 1 (not 2).

  6. Hierarchy level 3: The following is checked for node C version 1:

    1. Are there direct child nodes of node C version 1 that have not been versioned?

    2. The answer is yes:

      1. The node D version 1. This node is attached to the successor of node C version 1, node C version 2.

      2. The node E version 1. This node is attached to the successor of node C version 1, the node C version 2.

  7. Hierarchy level 4: For nodes G version 1, H version 1, D version 1, and E version 1 the following is checked respectively.

    1. Are there direct child nodes that have not been versioned?

    2. The answer is no.

  8. All 5 nodes have now been moved. 

  9. The subtree with the previous versions and its subnodes is still in the object

image-20240606-082529.png

Example step 2d

Node A version 1 and its children with the previous versions are deleted from the object.

image-20240606-082538.png

Example step 2e

The object only has the versioned and moved nodes.

image-20240606-082549.png

Example step 3a

Next, node G version 1 is to be versioned under ROOT A version 2.

  1. Node F version 1 is the parent node of node G version 1 and is released. Therefore, node F version 1 must be versioned.

  2. Node B version 2 is the parent node of node F version 1 and is "In Creation". Therefore, node B version 2 does not need to be versioned.

  3. Thus node F version 1 is the highest node below the ROOT, which must be versioned.

  4. Node F version 1 is versioned. The successor version, node F version 2, is appended under node B version 2.

  5. All necessary parents were versioned.

  6. Node G version 1 is versioned. The successor version, node G version 2, is appended under node F version 2.

  7. The old subtree with the previous versions (node F version 1 and node G version 1) and its subnodes are still in the object.

  8. The new subtree with the successor versions (node F version 2 and node G version 2) is also in the object.

  9. Now it is known which node in the object has been versioned and which has not.

image-20240606-082558.png

Example step 3b

The unversioned nodes must be moved.

  1. The move starts from the highest node in the object, the node with the smallest hierarchy, which has been versioned: Node F Version 1.

  2. The algorithm goes horizontally through the object. This means that all nodes of a hierarchy level and hierarchy number are processed in groups.

  3. Hierarchy level 3: The following is checked for node F version 1:

    1. Are there direct child nodes of node F version 1 that have not been versioned?

    2. The answer is yes.

      1. The node H version 1. This node is attached to the successor of node F version 1, node F version 2.

    3. There are no other nodes in this hierarchy level 3 and hierarchy number.

    4. The next node is checked.

  4. All the necessary nodes have now been moved. 

  5. The subtree with the previous versions and its subnodes is still in the object.

image-20240606-082610.png

Example step 3c

The node F version 1 and its children with the previous versions are deleted from the object.

image-20240606-082619.png

Example step 3d

The object only has the versioned and moved nodes.

image-20240606-082629.png