Push to Default should overwrite Dirty Areas in Default

[Greg_Mattis]

Every time I push a version to default, I introduce a dirty area in Default regardless of any validation efforts done while in the version therefore I am doing two sets of validation, once in the version and then the other while in default. My idea would be that if a version is pushed to Default, and validation workflows were successfully completed (resulting in no Dirty Areas) after reconciling but before pushing to Default, Dirty Areas should not exist.

@AmirBar-Maor @TimHodson @JasonCamerano 

[AmirBar-Maor]

@Greg_Mattis 

This is the expected behavior.

You can read more about it here: https://pro.arcgis.com/en/pro-app/latest/help/data/topologies/dirty-areas-in-versioned-feature-class...

Examples 4 & 5

@ColinZwicker please review my answer and add / correct.

Why?

1. It is safer: the default version might have changed between the time you have reconciled to the time you posted your changes.

2. Multiple versions might have been validated and free of errors, but when their edits "meet" in the default versions they might violate the topology rules.

[Greg_Mattis]

Hi @AmirBar-Maor 

Examples 4 & 5 do not outline the workflow I am referring to. The sequence I am referring to is:

Step 1: Create a child version

Step 2: Apply a geometry edit to the child version

Step 3: Reconcile the Child Version with the Default Version to get any changes that have occurred during the time between Step 1 and Step 2 occurred.

Step 4: Validate Topology

Step 4a: If errors occur fix errors and then redo step 3 and 4.

Step 5: Post to Default.

In the examples provided validating topology occurred prior to the reconciling I am proposing validating after reconciling.

As for the why's: I can understand 1 as being true if you are not reconciling and posting right away but this workflow has, in part, made the ArcGIS Pro Parcel Fabric Experience must slower than the ArcMap Parcel Fabric Experience.

As for 2, if multiple versions are validated and free of errors and once they meet in the default version, they violate topology rules I would expect that to result in a dirty area. But absent that case, I does not seem reasonable to make it a dirty area when topology rules aren't being violated.

[Colin_Zwicker]

@AmirBar-Maor 's summary is correct.

re #1, without holding an exclusive style lock on the default version during the entire reconcile and post progress the "right away" aspect of the timing is a racing condition that cannot be controlled. Blocking default is not an acceptable pattern.

re #2, "once they meet in the default version, they violate topology rules I would expect that to result in a dirty area" we agree, and utilize the generated dirty areas to identify the errors. Without the generated dirty areas there is no mechanism to validate the assigned topology rules for those features.

[CathyAppleton]

I want to be kept in the loop on this one.   I tried to kudos this one, but thumbs up is ghosted out.  Not sure why that is, I am guessing that is because status is set at "needs clarification"      So maybe later I will be able to 

[AmirBar-Maor]

This is not a parcel fabric idea.

Geodatabase topology and branch versioning are not unique to parcel fabrics.

Read the comments to understand the reasoning behind this behavior.