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.
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.
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.
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.
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.