Solved! Go to Solution.
How about the sequence of reconcile/post between the default ArcSDE geodatabase and these multiple versions? With which version the default ArcSDE geodatabase is first reconciled/posted?
For example, is the default ArcSDE geodatabase first reconciled/posted with Sami's version or Reda's version? which edits of these two versions are first transferred to the default ArcSDE geodatabase?
I'm still on 10.0, but the concept is the same.
Whether you reconcile Sammi or Reda's version first to default doesn't matter if they are both children of the parent default version. If there are conflicts, the reconcile/post process will tell you about them and you can specify which version to favor or manually review the conflicts.
However it is best to reconcile the parent/child line in order, based on which user owns/created the version.
You should be able to reconcile/post any of those child versions against default in any order. if there are conflicts, the process will inform you about them.
Then why the edits of the version of u1 are not transferred to the resulted default ArcSDE geodatabase while the edits of version of u2 are transferred to default ArcSDE geodatabase?
From this Help page:
"If you resolve conflicts in favor of the edit version, all conflicting features in the current edit session take precedence over conflicting representations in the target version."
1) You delete feature 10 in version U1
2) You start batch reconciliation and posting with the option "in favor of the edit version" as per your screenshot.
2) Reconciliation and posting of version U1 takes place, where feature 10 is deleted from the target database, no conflicts are detected in this phase.
4) Now reconcilation and posting of version U2 takes place, again "in favor of the edit version". A conflict is detected. U2 has the original feature 10 with an edit to its attributes, but this feature is deleted from the target. Since it takes precedence over the target version, where the feature is deleted, feature 10 is posted back to the target, including the attribute edit done in feature 10.
And yes, the deleted feature in version U1 is back...
Jamal, if you want detailed control over each conflict, you should review any edits manually, not run a "batch reconciliation" on multiple versions. ArcGIS has all these tools specifically for this reason: to allow you to make a good judgement of the conflict by thoroughly reviewing it.
As to best practices: multi-user edit conflicts are allowed and reconciliation supported in ArcGIS, but this doesn't mean you should be lax on good working practices. Well designed work flows and good work orders should always try to avoid conflicting edits as much as possible to avoid excess work in the conflict detecting & reconciliation.
What I wanted to highlight here is that the order of versions when reconciled/posted with the parent is determinant!
In my previous example, if the first version is U2 and the second version is U1 then feature 10 will be deleted from the target. Correct?
Not necessarily..., it may get a bit complicated now, but versions reference so called "database states". Each time you make any type of edit to a Feature Class, you create a new "database state", and the version starts referencing that state from that moment onwards until the next edit completes. The database state references a certain combination of records in the base table and A/D delta tables. Your single version may actually go through a whole set of "states" during its life-time until you delete the version once you no longer need it. Even during a single edit session (the time in between clicking Start Editing and Stop Editing in ArcMap), your version may go through multiple states, as you can perform multiple edits in a single edit session.
It is the time you complete your edits (transaction closing time?) to specific records / geometries, which ultimately determines which records / geometries might be considered the "valid" or last "state" of the object they represent. It is this time and database state information that is used in the (batch) reconciliation and post process to determine if there are any conflicts due to other users having edited, saved and posted the same object to the same target version before you post it. You can than use the reconciliation tools to review the conflicting states and determine whether you favor the current target, or your own edit version.
So don't confuse the creation time of the version with the save / completion times of specific edits to specific records / geometries.
Jamal, I also strongly encourage you to read Derek Law's basic introduction to versioning to better understand what is going on "under the hood":
And for a really comprehensive overview (older 2004 document, but the mechanism of versioning described there is still highly relevant):
Versioning - ESRI Technical paper
Thank you for the useful information you discussed, but after working on this issue, I found that the "reconcile versions" depends on the updated of the last created version. which is "rr" in the attached photo, and does not depend on the time or other factors. The edits of the version of "rr" are transferred to the resulted default ArcSDE geodatabase while the edits of versions of "mm"" or "nn" are not transferred to default ArcSDE geodatabase, this clarify that the reconcile depends on the last created version.