Developer

Update Conflicts and Conflict Resolution

When performing an update operation the local project is updated to match the tip revision of the share repository. When the update is performed, however, it is possible the state of the local application project is in conflict with the state of the share’s tip revision. This occurs, potentially, when the same definition is deleted or modified in some manner in both the local project and share.

During the update operation, the Agentry Editor checks for any conflicts. If found, it may be necessary for the developer to manually resolve these conflicts. This manual resolution is performed in the Comparison View in the Agentry Perspective. This view is displayed whenever an update operation is performed. If a conflict is found, a message is displayed after the update is finished indicating there is an issue. Any definitions in the tip revision not in conflict with the local project are imported. Those in conflict are not imported, but rather are highlighted as differences in the comparison view.

This manual conflict resolution is similar in behavior to a compare and import from some other import source, such as an export file. The local project and the share’s tip revision are displayed in the comparison view, with the share on the right side as the comparison source. The developer can then select the individual definitions within this view to be imported from the share, or leave them as is within the local project. This selection can be different for each definition found to be in conflict.

When the conflict resolution is completed by the developer, the definitions selected in the share are imported into the local project. Any conflicted definitions not imported from the share are left unchanged in the local project. At this point a commit can be performed and those definitions not imported from the share are committed to the share as a part of the new revision.

The nature of the conflict and how it should be resolved depends on the type of changes made to the definitions in both places. The following list describes the potential conflicts requiring manual resolution by the developer. This list is then followed by sections describing the resolution choices for each:
  • Share definition edited - local definition edited: In this situation, both the share and local definitions’ attributes have been modified in some manner. Since the nature of the change to both may not be compatible in one manner or another when merged, this change is left to the developer to resolve.
  • Share definition deleted - local definition modified: If the local definition has been edited by the developer, and the same definition is deleted from the share revision, the developer must specify whether to keep the local definition, or to import the deleted definition from the share.
  • Share definition deleted - local definition modified and deleted: If the share definition has been deleted (contained in the trash bin) and the local definition was modified and then deleted, a conflict exists. While the share definition is simply added to the trash bin if brought down during the update, there is a question as to which version of this definition should be stored in the trash bin for possible later recovery, the local version or the share version. Therefore, the developer is required to make this selection.

Share Definition Edited - Local Definition Edited

If both the local definition and the definition in the share have been edited, a conflict exists and must be resolved manually. Edited share and local definitions includes changes to the definitions’ attributes, whether or not it is the same attribute. Changes to child definitions are not considered conflicts.

When such a conflict occurs, the developer must manually specify in the Comparison View which definition to keep. If the share definition is selected in this view, it will be imported into the local project, replacing the local definition. If the share definition is not selected, the local definition will remain. During the next commit from the local project, the local definition that was in conflict will be treated as a changed definition and committed to the share.

Share Definition Deleted - Local Definition Modified

If the definition in the share has been deleted, and the local definition has been modified, a conflict exists. Any change to any attributes in the local definition constitute a change. The share definition is considered deleted if it has been removed but remains in the trash bin. Permanently deleted definitions in the share repository, that is, those that have been removed from the trash bin, and those that have been edited in the local project are not conflicted.

Share Definition Deleted - Local Definition Modified and Deleted

If the share definition has been deleted and resides in the trash bin, and the local definition has been modified and then subsequently deleted prior to committing, a conflict exists. In this situation, the developer must compare the two definitions and determine which should reside in the local trash bin.

If the share definition is selected in the Comparison View, the local definition in the trash bin is replaced with the share definition. Otherwise the local definition remains in the trash bin and will then be added to the next commit performed from the local project.

Automatically Resolved Conflicts

Additional conflicts may occur during an update from the share’s tip revision that will not require intervention on the part of the developer. These may not even be considered conflicts, but rather the behavior of the update operation under certain conditions other than when the local definition has not been modified and the share definition has.

The following list describes these situations and the resulting behavior of the update:
  • Share definition deleted in trash bin - local definition not modified: If the share definition has been deleted and currently resides in the trash bin, and if the local definition has not been modified in any way and matches the share definition, the local definition is removed from its parent and placed in the trash bin.
  • Share definition deleted - local definition deleted, not modified: If the share and local definition have both been deleted, and if there is some difference with the local definition that is not tagged, meaning it was not made since the last commit, the share definition will replace the local definition in the trash bin.
  • Share definition deleted - local definition does not exist: If the share definition is deleted and resides in the trash bin, and there is not corresponding local definition, the share definition is added to the local project and resides in the trash bin.
  • Share definition does not exist - local definition exists, not modified: If the local definition exists and has not been modified, and the share does not have a corresponding definition, the local definition is not modified or removed. This is listed as a difference in the Comparison View and can be removed here or by simply deleting the definition. If the definition is not removed from the local project it will be added to the share during the next commit operation.