Is This Content Helpful?
We're glad to know this article was helpful.
During reconcile, ArcGIS finds all of edits that have occurred on two lineages to determine the conflicts. The edits that are processed are all the edits on the lineage back to the common ancestor state. Depending on the reconcile and post order of your versions, unexpected conflicts on edits may occur. Please see the following example:
1. Consider three versions; all these versions reference state_id 0:
2. Edit the default version feature (objectid #10) and child version feature (objectid #11). Default version state_id is 1 and child version state_id is 2.
3. The child is reconciled and posted to parent version. Now parent and child both points to state_id 4. The lineage for these versions is 0, 2, 4.
4. The parent version is reconciled and posted to default. The edits to object #11 that occurred in the parent's branch are copied to state 6.
5. Hence this object #11 is edited now at state_id 2 and 6.
6. Now both parent and default point to state 6. The lineage for these versions is 0, 1, 6.
7. The child version still refers to state_id 4 with lineages 0, 2, 4.
8. Currently, all three versions reference an edit occurring to object #11. In the child version, the edits to object #11 occurred at state 2 while in the parent and default versions, the edit to this feature occurred at state 6.
9. Edit child version for same object id #11 at state 7. Now the child version has lineages 0, 2, 4, 7.
10. Next, the child is reconciled to parent again. Upon reconcile, a conflict is found with objectid #11 which is unexpected.
The conflict occurs because during a reconcile, the lineage of the edits back to the common ancestor is evaluated. In this situation, the lineage for parent is 0, 1, 6 and lineages for child is 0, 2, 4, 7.
• At state 6, objectid #11 was edited.
• At State 7, objectid #11 was edited.
Because the same object was edited in both lineages, a conflict is detected.
These false conflicts can be avoided by the following workflow.