Sequence of reconcile/post from multiple versions to default ArcSDE geodatabase,

[JamalNUMAN]

Sequence of reconcile/post from multiple versions to default ArcSDE geodatabase,

Multiple versions are created from the default ArcSDE geodatabase. I couldn???t figure out how the reconcile/post is performed?


[ATTACH=CONFIG]25154[/ATTACH]

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?


Thank you

Best

Jamal

[Anonymous User]

Original User: Jamal432@gmail.com

Jamal, if by this, you mean you hadn't expected feature 11 to move in SDE.DEFAULT because you set "FAVOR_TARGET_VERSION", than you are forgetting that you didn't edit feature 11 in the SDE.DEFAULT, you only edited feature 11 in the versions u1, u2 and u3.

Since you didn't edit feature 11 in SDE.DEFAULT, there is NO edit conflict for feature 11 between SDE.DEFAULT and u1 once you start reconciling. Hence the edit of feature 11 in version u1 is posted to SDE.DEFAULT, and feature 11 thus moves in SDE.DEFAULT.

If you want to see the other result as a test, namely a feature 11 that does not move with the edits in other versions, you will need to create a conflict by editing it in the SDE.DEFAULT as well, and setting "FAVOR_TARGET_VERSION", and than reconcile and post. This is what you did with feature 10, you moved it in SDE.DEFAULT. As a consequence, feature 10 in SDE.DEFAULT is in conflict with u1, and since you set "FAVOR_TARGET_VERSION", feature 10 remains as it is in SDE.DEFAULT after the reconciliation and post.

ArcGIS is behaving exactly as expected!

Thank you very much Macro for efforts for explaining the precise behaviors of versions as they are reconciled/posted

It is very clear now.

One behavior is still missing. I need the conflict to be resolved on favor of target (default.sde) but based on the �??LAST SAVE TIME�?� of all other versions!

1. I expect that feature #11 must be updated based on u3 (blue color) and thus THE SPATIAL LOCATION SHOULD GO TO THE �??BLUE�?� COLOR NOT TO THE RED

2. I expect that feature number #10 will be updated based on default.sde and thus the spatial location must go to the �??black�?� color (this is OK as the edits are controlled by the target version)

Please, have a look on the screenshot below:

[ATTACH=CONFIG]28374[/ATTACH], [ATTACH=CONFIG]28375[/ATTACH], [ATTACH=CONFIG]28376[/ATTACH], [ATTACH=CONFIG]28377[/ATTACH]

[MarcoBoeringa]

1. I expect that feature #11 must be updated based on u3 (blue color) and thus THE SPATIAL LOCATION SHOULD GO TO THE �??BLUE�?� COLOR NOT TO THE RED

Jamal, you are still missing a point here, and I explained this in my last post. This is what is happening for feature 11:

1) Since in these last screenshots you posted, you don't edit feature 11, feature 11 isn't in conflict with u1. This means the edit of u1 will be posted to target SDE.DEFAULT.

2) Next u2 will be reconciled against target SDE.DEFAULT. Since feature 11 in SDE.DEFAULT now changed based upon the edit in u1, it now IS in conflict with feature 11 in u2! Since you set "FAVOR_TARGET_VERSION", the edit in u2 will be ignored and SDE.DEFAULT remains the same.

3) The same holds for u3, feature 11 in u3 is in conflict with the target SDE.DEFAULT, and hence the edit of feature 11 in u3 will be ignored / discarded too.

As a consequence, feature 11 in SDE.DEFAULT will be based on the edit of u1.

You will need to set "FAVOR_EDIT_VERSION" in case you want the edit of feature 11 in u3 to be incorporated in target SDE.DEFAULT.

As you can now also see, the status of being "in conflict" or not, can change during the batch reconciliation, as each edit version is reconciled and posted one after another...

[Anonymous User]

Original User: Jamal432@gmail.com

Jamal, you are still missing a point here, and I explained this in my last post. This is what is happening for feature 11:

1) Since in these last screenshots you posted, you don't edit feature 11, feature 11 isn't in conflict with u1. This means the edit of u1 will be posted to target SDE.DEFAULT.

2) Next u2 will be reconciled against target SDE.DEFAULT. Since feature 11 in SDE.DEFAULT now changed based upon the edit in u1, it now IS in conflict with feature 11 in u2! Since you set "FAVOR_TARGET_VERSION", the edit in u2 will be ignored and SDE.DEFAULT remains the same.

3) The same holds for u3, feature 11 in u3 is in conflict with the target SDE.DEFAULT, and hence the edit of feature 11 in u3 will be ignored / discarded too.

As a consequence, feature 11 in SDE.DEFAULT will be based on the edit of u1.

You will need to set "FAVOR_EDIT_VERSION" in case you want the edit of feature 11 in u3 to be incorporated in target SDE.DEFAULT.

As you can now also see, the status of being "in conflict" or not, can change during the batch reconciliation, as each edit version is reconciled and posted one after another...

Many thanks Marco,

This brings us back to the first question.

Why the ArcGIS starts reconciliation with u1 but not with u2 or u3. For example, if the system starts with u3 then feature #11 will be updated based on the location of the u3 but not based on the location of u1. (Sequence is still not clear for me)

In other words, I'm looking for the following behavior:

1. In case of conflicts: all should be updated based on the default.sde version
2. In case where there is no conflict: all should be updated based on the �??last save time�?� (in our case updating must be made based on changes on u3 but not u1)

Is that possible?

*If the type of conflict resolution is chosen to be �??in favor of edits�?� then the default.sde will be updated based on other versions in case of conflict! This is risky (screenshots below)

[ATTACH=CONFIG]28397[/ATTACH], [ATTACH=CONFIG]28398[/ATTACH], [ATTACH=CONFIG]28399[/ATTACH], [ATTACH=CONFIG]28400[/ATTACH]

[MarcoBoeringa]

*If the type of conflict resolution is chosen to be �??in favor of edits�?� then the default.sde will be updated based on other versions in case of conflict! This is risky (screenshots below)

Jamal,

No, this isn't risky, it is a choice. A choice that you as the user consciously make or not. There is no "good" or "bad" here.

To make this more clear: let's for the sake of it assume there are two editors "A" and "B". "A" makes an edit to his version and saves at 10:05:34 AM. Now "B" makes a conflicting edit in his own version and saves at
10:18:56 AM. Now who made the right edit? Is it "B" because he saved the last? Or "A" because he had the right papers, and "B" was accidentally given the wrong dossier?

I hope you will agree there is no way to tell if A or B was right in case of a conflict, and certainly NOT based on something as arbitrary as a "save time". Only a review of what A and B did, and what paper sources or dossiers they used for the edits, might reveal who was right and who was wrong, so who made the error causing the conflict.

And even if there is no conflict at all, any edits in any version including the DEFAULT might be wrong, because who is telling you your employees are doing their job right? (of course, I hope they do!).

ArcGIS and the versioned editing environment does, of course - and logically - assume that any non-conflicting edits must be posted to the target based on the order of the save times / states, this is why the "edit versions" are listed in the recommended reconciliation order, the way they are visible in the Reconcile Versions dialog.

I do have the feeling that you keep forgetting that editing conflicts, in a healthy well designed workflow, should be the absolute *exception*. If the workflow of your organization causes hundreds of editing conflicts, no (semi-automated) tool anyone at ESRI can devise, will solve the mess with you leaning back in your chair watching it happen!

You should always ensure your workflows are good, than use reconciliation to fix the few errors left in a controlled and conscious matter.

This may also mean no batch reconciliation, but one-by-one reconciliation with review of someone with authority to make the decisions to solve the conflict (most likely after a short investigation to find out what went wrong, and what the right state of the features involved should be based on the latest information gathered).

[Anonymous User]

Original User: Jamal432@gmail.com

Jamal,

No, this isn't risky, it is a choice. A choice that you as the user consciously make or not. There is no "good" or "bad" here.

To make this more clear: let's for the sake of it assume there are two editors "A" and "B". "A" makes an edit to his version and saves at 10:05:34 AM. Now "B" makes a conflicting edit in his own version and saves at
10:18:56 AM. Now who made the right edit? Is it "B" because he saved the last? Or "A" because he had the right papers, and "B" was accidentally given the wrong dossier?

I hope you will agree there is no way to tell if A or B was right in case of a conflict, and certainly NOT based on something as arbitrary as a "save time". Only a review of what A and B did, and what paper sources or dossiers they used for the edits, might reveal who was right and who was wrong, so who made the error causing the conflict.

And even if there is no conflict at all, any edits in any version including the DEFAULT might be wrong, because who is telling you your employees are doing their job right? (of course, I hope they do!).

ArcGIS and the versioned editing environment does, of course - and logically - assume that any non-conflicting edits must be posted to the target based on the order of the save times / states, this is why the "edit versions" are listed in the recommended reconciliation order, the way they are visible in the Reconcile Versions dialog.

I do have the feeling that you keep forgetting that editing conflicts, in a healthy well designed workflow, should be the absolute *exception*. If the workflow of your organization causes hundreds of editing conflicts, no (semi-automated) tool anyone at ESRI can devise, will solve the mess with you leaning back in your chair watching it happen!

You should always ensure your workflows are good, than use reconciliation to fix the few errors left in a controlled and conscious matter.

This may also mean no batch reconciliation, but one-by-one reconciliation with review of someone with authority to make the decisions to solve the conflict (most likely after a short investigation to find out what went wrong, and what the right state of the features involved should be based on the latest information gathered).

Hi Marco,

I�??m really very thankful for the help you have offered. My understanding for reconcile/post of versions is much better now. I appreciate that you are sharing your experience in this field.

Best

Jamal

[JamalNUMAN]

This question is still valid in ArcGIS Enterprise (Pro 3.0.1)

Not sure why the edits occurred on the child versions are posted to the parent based on the date the child versions created but not the date the edits occurred in each version

Consider the scenario below:

• Assume that a parent version has 3 children versions ch1, ch2, and ch3 that are created respectively
• Now, suppose that the same feature is edited by ch3, ch1, ch2 respectively
• As the “post” is applied, then the parent versions will be edited based on ch1 despite the fact that last time editing has been performed was in ch2 version.

This means that parent is modified based on the DATE the versions created but not the DATE the last edit made (regardless on which child version)

My understanding is that the parent should take the last edits made regardless the child version this editing is made in

[Kevin_MacLeod]

@MarcoBoeringa , I understand your point of users editing different work areas of a feature class, or of only editing different layers altogether.  However for various reasons that may not be realistic.   A tool to systematically view Differences and Conflicts between two or three or more children,  before posting to Default, would greatly assist in semi-automating QA/QC.  For now the only thing I can think of, is to have an intermediate child Version to one-by-one post GrandChildren to, to see Differences and Conflicts.   (Default->Child-> Grandchild 1, Grandchild 2, Grandchild 3)

It would be great if there was a way to view Differences and Conflicts between Children at the same level, before posting to Default. Or to any parent.

I posted a question before coming across this thread.  https://community.esri.com/t5/data-management-questions/is-there-a-way-to-compare-between-multiple-c...  

Basically, seems like it's not possible?  Someone posted some arcane SQL to do it but if it's not possible in a GUI I'll just muddle through by creating an intermediate version and one by one looking at Differences, which is the only way I can think of seeing differences, one by one, between multiple children, before posting all the way up to Default. 

Ideally, 3 things would be possible:

1) ability to view differences and conflicts between child versions at the same level (child to child)

2) ability to accept/reject/modify in the Differences Panel one by one. 

3) ability to Post only some feature classes, not all feature classes in the database, up Default or to a parent. Furthermore, ability to post only certain records (features) in a featureclass, based on an attribute. For example if I added a field marked 'approved' and then marked all the Posted features from Child 1 in Default as 'Approved'; then posted Child 2 with a filtering query, so only certain records in certain feature classes were Posted up from Child 2.  I see the Conflict Filter tool in the toolbox and will experiment; hopefully that can exclude entire feature classes too.