Detecting Conflicts in Workspaces and Applying Resolutions
In a development environment where multiple users work in parallel making configuration changes concurrently in their own private Workspaces, conflicts might arise when the same objects and attributes are modified by different users in their own private Workspaces, and then the changes from these users are delivered to the MAIN branch. These situations often lead to non-trivial merges because of the conflicting changes between different users.
For Workspaces, the system detects the conflicts prior to Workspace delivery. If conflicts or errors are found, the system displays the issues along with the default resolutions. You must review the conflicts and resolve the issues.
In other words, during the rebase Workspace process, the system enables you to:
-
Identify the conflicts by viewing the conflict flags on the attributes. Notice that some conflicts must be explicitly resolved before you can submit the Workspace for delivery again.
-
Identify the errors by viewing the status message of the objects or attributes.
-
View the status message that describes the error or conflict in details for each object or attribute.
If the system cannot resolve the conflict or the delivery process encounters an error while merging the changes, an error message appears. Although an attempt is made on all objects, the overall delivery process fails even if a single error is encountered.
WS_REBASE_<wsname><rebase attempt number>.log, located in
the standard Siebel log folder. For example,
...\ses\siebsrvr\log.Conflicts and errors can be broadly categorized as follows: Attribute-Level and Object-Level (for example: name conflicts, object inactive conflicts, and index violation errors).