When Versioning with ArcSDE can posted edits be cancelled or rejected?

Ugh. The answer is really a complicated one that requires a lot of ArcSDE background, so I will try to be as brief as possible.

Note I am going to refer to some diagrams from the super awesome versioning white paper that you can find in the ESRI site. If you are dealing with versioning, I extremely encourage you to read it throughly.

Then, you need to understand what is the relationship between a state (i.e a node from the state tree) and a named version (i.e a label pointing to a state).

A typical database may look like the state-diagram below:

Here, you have four versions in the database (Version A, Version B, Version C and DEFAULT). But perhaps, I am getting a little ahead of myself. Let's start with what a state is.

You can think of a state as a "transaction" - a logical unit that contains several edits to one - or many - tables. It may include two inserts to "FeatureClass A", a delete from "Feature Class B" and a modify (effectively a delete + an insert) to "Feature Class X". All grouped into one.

Let's look at a small, simple, ArcSDE state diagram that starts at state id 0:

If you start at state 0 and you do edits to one or many tables in an edit operation, you will create a child state 1 and make that one the current active state id. Another subsequent group of edits will create child state 2. If you want to undo, you don't need to modify the state id in any way - all you need to do is change the current active state id to 1, or 0 (depending how far back you want to go). A redo is the opposite - just move the current active state id forward - as far forward as you want to go.

That is how undo/redo works in ArcSDE versioning.

OK, moving on. Say, that you want to make an edit permanent (i.e, you want to save). What do you have to do? Well, saving is just grabbing a version label and moving it forward to a particular state. Kind of like stamping it and saying "this is what Version A must look like". So if you look back at the first diagram, you will see that it has four named versions.

• Version B points to state id 1

• Version A points to state id 3

• Version C points to state id 5

• Version "SDE.DEFAULT" points to state id 4

  Please note that this diagram, despite popular belief, does not tell you anything about the logical parent-child relationship that they have. The logical parent-child relationship for the first diagram could effective look like this:

This is the parent-child relationship that you see in ArcMap/ArcCatalog. It's purpose, is to restrict which versions you can reconcile against. At this point, you could (rightfully) be asking yourself, why the hell do I need this? The answer, lies in versioning workflows. Turns out, people have been using versioning for quite some times and there are some preferred ways of how to structure these, but that is a topic for another day since I want to answer your question today :)

Moving on...

OK, so what else do this named versions do? Well, they affect how this process called compress behaves.

Compress is all about grabbing intermediate states that may not be necessary, and removing unnecessary ones as well as combining them. You can trigger the ArcSDE compress operation through ArcCatalog, setup a service that does it every one in awhile, and some ArcMap edit operations will trigger mini-compress operations (i.e just for small branches that are being used).

The diagram on the left shows a state tree before it gets compressed, and the one on the right shows it right after it gets compressed:

An important concept to understand (which I will refer to you once I finally get to answer your question) is that every single state is a potential candidate to be compressed - except states that have labels (i.e named versions) pointed at them.

You can see that before the compress there are some extra - unnecessary states. In fact, the entire [3,4,5] branch got removed. Had there been a named version at 5, the end result would have been very different.

Compress operations are there to save space on your database by removing records you do not need anymore.

OK, moving on.

The last concept that you need to understand, is reconciling - which is effectively merging two branches into one.

So let's go back to our very first diagram. Say that you want to reconcile Version A against SDE.DEFAULT.

Let's recap: four named versions pointing to various state ids. So the first thing that we have to do, is create a child state under the target version, so we create a child state under state id 4, in our example, I call that state id 20.

The next step is to calculate the differences between both versions (the details are too long for this post, but I can tell you that they are done with difference cursors) and then applying those differences to that new state id 20 (blue line).

Say that you decide to do more edits or that you found conflicts and are choosing rows from one version, or the other. It doesn't matter. Those are just new edits, and are done inside an edit operation, as child states underneath the branch that you merged. In this example, I have done two more consecutive group of edits after the reconcile.

Lovely.

So now say that you are ready "post" the version. What does that mean? That is just grabbing the labels and pointing them to the same state id. Here, I am going to post Version A to SDE.DEFAULT. This is what it looks like:

TADAAA! So now Version A and SDE.DEFAULT are pointing to the same state id, and thus they look the same.

OK, so now I can finally answer your question.

Can you undo a post? The ArcGIS documentation will tell you no - don't mess with it. Don't do it, because you will be messing with this logic, and if you don't know what you are doing, you can corrupt your data.

But in truth, all it takes is to do one update of one of the ArcSDE Versioning tables - the VERSIONS table, and modify the entry of the label (aka named version). In our example, point to state id 21, and you have just undone that entire edit operation. Set it to 3, and you just undid the entire reconcile. Set it to 5, and now you are in a completely different place. Whether there are or there are not conflicts is irrelevant.

Of course, this assumes that a compress has not happened. Let's consider the case where the compress is happening right at the exact same time you are updating the SDE table. Remember, if you - or somebody else - executes a compress after you posted this is what the tree looks like:

Can you undo the reconcile after the compress? Well, in this case, no. The compress has blown away that entire branch, so you cannot undo - that data has been removed. Had there been another named version on that branch, then the compress would not have destroyed that branch. I hope that by now this makes sense.

So should you do this? Up to you, if you don't know what you are doing, you can easily loose data after a compress.

There is tool called Geodatabase Toolset (GDBT), which is a plugin to ArcCatalog. It visualizes the state linage and versions:

Download GDBT here

Short of knowing the version and db. here is some initial information that will help you.
Basic admin
Here is some info on rec and post
So if you apply these concepts and use the version changes command you still have the opportunity to reject those changes when you rec and post to default.

You don't have three copies of the same database.
You have one copy with versions.
If you are administering this db you really shoud spend the time (maybe even money) and become familiar with all of this.
The esri class Versioned Editing Workflows for the Multiuser Geodatabase is free and will help some.
But the full monte would be what I recommend for a person administering any kind of versioned sde editing workflow.
That class is Great! for understanding Versioned Editing Workflows for the Multiuser Geodatabase.