a version contains an unwanted change to the target

[GeorgeRiner]

We use versioning as a sort of QC tool in our office. One person creates a version, saves their edits to it, and then a second person reviews the version and, if all seems OK, posts it back to the target. This gets two sets of eyes looking at things before they're incorporated into the production database. After posting, the version is deleted. We have about 15 datasets (layers) that we manage this way and the features in them overlap spatially. During an edit session, it sometimes happens that a polygon, say, is inadvertently edited. This unintended edit gets into the version along with all the other intended edits. We see these unintended edits when the second person looks at the version and sees them in the Version Changes window. These unintended edits are NOT conflicts - no one else has changed (or deleted) the same polygon. There are no reconciliation errors. The version contains one edit (out of 40 or 50, e.g.) that we don't want.

We'd like these mistaken edits to not post to the target, but we don't want to throw away all the intended edits that are in the same version.

How can we remove these mistaken edits from the version so we can post just the remaining valid edits to the target?

The Version Changes window lists all the changes in the version (when compared to the target). What I search for is to click on one of these changes in the window and say "remove this change from this version" ? But there may be some other way to achieve the same effect.

[847396730]

Is it logical/feasible to just fix it?  And then, if you haven't already, adjust permissions on your tables such that only the intended feature classes are edited.

[GeorgeRiner]

These kinds of mistakes happen because the work is done in one feature class where the individual features are allowed to overlap. During the process of creating/editing a polygon, a pre-existing polygon gets mistakenly selected and changed while manipulating the intended new polygon. The inadvertent selection of a mistaken polygon isn't noticed until after the person completes their edit sessions for their version and turns it over to the second person to review. Just to provide some context: these edits can take several days (sometimes a week or two) to do before the version is turned over for review. Put simply, by the time the second person notices the mistaken change to an unrelated polygon, what has been changed about it is unknown - as the person doing the original edits was unaware that they were changing it - or when they changed it. "Fixing" it would involve determining what the original shape of the mistakenly-edited polygon was - and then trying to detect which vertices were moved and moving them back to their original locations. To find their original locations, one should refer to the polygon as it exists in its un-changed form back in the target db!

I have fixed this on occasion by switching back to the target db, copying out the original polygon, switching back to the un-posted version and deleting the mistakenly edited polygon and pasting in the original polygon. This is tedious and creates a delete and an insert in the version for a polygon that logically should have not been touched at all. Instead of all this fixing to the updated polygon, I just need to have the update to that polygon in that feature class removed from that version before the version is posted. The Version Changes window presents the version in terms of Inserts/Deletes/Updates within each feature class. Removing the update to the unintended polygon would leave it in the db with its original ID and date-time stamps and user id's and it wouldn't start showing up in reports about what was changed last week or last month, etc.

Maybe we could set permissions on the various feature classes so that when editing feature class A, nothing can happen to feature class B - but our situation here is that the person is working in feature class A and inadvertently edited a polygon in feature class A.

[847396730]

Would it suit your workflow to create a layer file for the users which splits the features into two or more sublayers?  You could make the layer with the pre-existing features non-selectable, and the layer with desired edits selectable.  It could be a def query based on date, user, some attribute.

[VinceAngelo]

The only way you could isolate a single edit using versioning would be to change
your editing paradigm to create a new version with each edit (a "fan" of states
off a starting state, vice a chain of edits in the state tree).  There is no supported
way to retroactively remove a single state change from the middle of the state tree.

- V

[GeorgeRiner]

We don't use nested trees of states. We create a 'batch' version off the root data and the delete it after it's posted. (Assuming that your use of "state" is synonymous with "version") so the version/state in question is a terminal node from the root tree with no intervening states/versions - so there is no "middle" of the state tree that I'm aware of.  As for 'retroactively remove', I'm looking for a way to remove the particular change before the version is posted to the target, not after - what I'm looking for doesn't seem retroactive.

DefQueries do work sometimes. Although I haven't experimented with trying to do a defQuery on a polygon that has yet to be created.

Sounds like we'll just have to be more careful when editing, and when mistakes happen, just do the delete/insert dance to pull the original polygon into the version. Versions are just a take-all or take-none proposition. Perhaps we could create a new version (off the same root as the problem version) and copy over the desired changes, leave the undesired change behind in the problem version - post the new version and delete it and delete the unposted problem version. This seems even more tedious than the delete/insert thing, but at least it leaves the original mistaken polygon in its original condition.

[VinceAngelo]

While the name of the optimistic locking scheme is "Versioning," it's not versions,
but "states" which form the basis for implementation.  Each edit is a state in the
state tree, and a version is merely a named state.  The Versioning 101 article
explains the details.

- V

[GeorgeRiner]

Ah... I wondered if that was the case. Thanks.