How to undo edits in a named version (branch versioning)?

Question

This is the scenario we plan to use branch versioning to. No testing done yet, but need to know it this is possible:

- A editor creates a named version and makes some edits to layers in a feature service from ArcGIS Pro.

- They change the ownership of the version to the Admin user so that admins check changes using the Differences pane (Versioning tab > Version Changes) before reconcile and post is done.

- An admin realizes some features that where modified, deleted or whatever shouldn't have been changed. Now, how can they recover the original features?

Rohanrajan · Answer

Is there any better way than Copy Pasting to recover data after the faulty POSTS to default. GlobalId retention is required in my case.

AGP · Answer

If the admin notices features that should not have been edited while reviewing the Version Changes page, individual edits can be selected and replaced with their "ancestor" version from the same page.

But, are you talking about the Differences view or about the Conflicts view?

They look almost the same according to the documentation (pics taken from ArcGIS Pro help), but do they really have the same options?

I know the Conflicts manager has the 'Replace with common ancestor version' option when reviewing conflicts (if any detected) right after the reconcile is done (see Manage branch version conflicts), but I can't find documentation about the availability of this same option in the Version changes page (see View branch version changes).

jcarlson · Answer

Can you clarify: in the editor's version, have edits been reconciled and posted in this scenario or not?

If the admin notices features that should not have been edited while reviewing the Version Changes page, individual edits can be selected and replaced with their "ancestor" version from the same page.

If the admin is noticing such features after posting, you can still access the original features by looking at a historical moment, which you can get to from the Versioning tab. Simply choose a date/time before the edits were posted, then copy the original features and paste them back into the live data. It can help to have two maps open side by side for this, one with the historic moment, the other with the live data.

The downside of the copy/paste approach is that you will be creating a new object in the layer, as opposed to reverting an object back to a prior state, but other than the globalID / objectID, the other attributes should be the same.