1. Using Siebel Tools
  2. Name Conflicts

Name Conflicts

A name conflict occurs when there are two different objects of the same type that have the same combination of name and parent ID. A potential violation of user key is detected as a result of the rebase operation, and the merge process selects a default resolution of renaming the object that belongs to the child Workspace by appending the string -[Rebase]. Both object and name attribute are marked with a conflict flag in the Merge Conflicts dialog box.

Here is an example of how a name conflict can occur:

  • Suppose that both User1 and User2 are working on changes for an upcoming release being developed in the IWS int_January. Each user creates a Developer Workspace under int_January\0 as follows: dev_user1_Workspace and dev_user2_Workspace.

  • User1 creates a new business component named Widget and delivers that change to the parent IWS, creating a new version int_January\1.

  • User2, who is unaware of User1’s changes, also creates a new business component with the same name (Widget), tests it, and attempts to deliver it to int_January.

  • User2's changes cannot be delivered because this is a non-trivial merge and it requires a rebase.

  • During rebase, the merge process detects that there is a name conflict so it renames the object in dev_user2_Workspace to Widget-[Rebase], and shows this as a conflict in the Merge Conflicts dialog box.

If a name conflict is not resolved, then subsequent delivery fails by identifying the system-generated name. This conflict cannot be resolved by selecting the Override option, but you must finish the rebase process and resolve it in either one of the two methods described in this example:

To resolve this conflict, it should be determined whether the users intended to create two different objects or the same object.

  • Case1: The users were creating two logically different objects but happened to choose the same name. In this scenario, the second user must rename the duplicate object to a different unique name (such as Super Widget).

  • Case2: If the users were creating the same logical object, the second user could revert to a previous version containing the dev_user2_Workspace Widget object and export it to an archive (SIF) file, then import it into the rebased version, using the archive capabilities to select which attributes to keep.