Lifecycle Based on Branches
This section describes the mechanism how the Solution Documentation provides lifecycle versions for the Solution Documentation, that means for the process structure, the attributes and the Knowledge Warehouse documents. This versioning mechanism is based on branches. A branch is a versioning context in which the Solution Documentation may be maintained, developed further or adapted and has the following main features (see also Basic Terms and Concepts):
Each solution has a production branch context.
A branch may have one or more child branches which can be used as separate versioning contexts. The changes done in a child branch may be brought back to its parent branch by a release operation for the changes.
A maintenance branch can be defined as a single special child branch of the production branch.
This topic covers the general mechanism and the main concepts in an overview and makes you familiar with the general lifecycle mechanism and with the features to view and evaluate changes.
If a maintenance branch exists for a production branch then the production branch version is locked for changes and thus cannot be modified directly. In this case the production branch version can only be changed via a release of the maintenance branch or a release of another child branch. Although the production branch version may not be edited it can be displayed in the Solution Documentation.
Change Granularity
The granularity of changes which are handled and versioned in a branch context is as follows:
For an element (a structure element displayed in the browser or an assignment element displayed in the object list), the structure information is handled as a whole. The structure information comprises the element existence, the parent element to which the element is assigned and the order of the element with its siblings (same-level elements).
Every attribute is handled separately. A multi-valued attribute like countries is regarded as one attribute.
A Knowledge Warehouse document is handled as a whole together with all document attributes.
Change Conflicts
A change conflict arises if after a change of a specific element in a child branch context the same element is also changed in the corresponding parent context. In this case, the change done in the child branch cannot be brought back automatically to its parent branch. The change conflict has to be resolved before.
Maintenance Conflicts
The changes done in the maintenance branch are typically corrections which have priority over other changes done in other branches. Therefore there are special change rules concerning the maintenance branch. An open correction blocks the release of other changes for an element, that means if a specific element has been modified in the maintenance branch and the modification has not yet been released (open correction) a change to the same element done in a parallel sibling branch cannot be released. A maintenance conflict cannot be resolved before the open correction has been released. As soon as the open correction has been released in the maintenance branch the maintenance conflicts become regular conflicts which can be resolved and then the change can be released.
Visibility of Changes
A change which has been done in a branch context is neither visible in its parent branch nor in any of its sibling branches. The visibility of a change in a child branch may be hidden by a conflicting change in the child branch. All non-conflicting changes are immediately visible in the child branch. The conflicting changes are not directly visible in the child branch.
Change Status
The change status of each element is available via the list view or search result and can be used as a filter (choose Group by -> Change Status
). The change status refers to the status of the element in the current branch context. Possible status values are:
Changed
: The element has been changed in the branch.Conflict
: There are conflicting changes for this element in the parent branch.Unchanged
: The element has not been changed in the branch.Created
: The element has been created in the branch and does not yet exist in the parent branch.Deleted
: The element has been deleted in the branch and does still exist in the parent branch.Maintenance Conflict
: The element has been changed in the branch as well as in the sibling maintenance branch of the parent branch.
More detailed information on the changes of the branch are displayed in the attributes panel if the options Change Tracking Mode
and Display Deleted Elements
are active. You activate these options in the settings.
Lifecycle Operations
The lifecycle operations are available for each element via the context menu. The operations in Element Change
affect only the element for which the context menu was called. The operations in Subtree Changes
affect the element and all elements in the subtree.
Release Changes
The element changes of the branch are applied to the parent branch.
Discard Changes
The element changes of the branch are removed. Discarding the changes in the branch context means to go back to the version of the parent branch.
Mark conflicts as resolved
The element version in a branch is marked as conflict free to the current version in the parent branch context. A conflict free change may be released to the parent branch. Conflicts may not occur in a maintenance branch.
Rules for Lifecycle Operations
It is not possible to release changes of elements with the status conflict or maintenance conflict.
It is not possible to discard changes of elements with the status created without discarding the changes for all sub tree elements with the status created.
It is not possible to discard changes of original elements with the status created without discarding the changes for all reference elements with the status created.
Releasing the deletion of an element follows the same rules as the deletion of the element in the parent branch.
A lifecycle operation can only be executed if none of the above rules is violated.