arcpy.ReconcileVersions_management WITHOUT reconciling all other versions at the same time

[MattFrancis]

In a versioned, enterprise environment, we have several versions that are children of default, lets call them Inky, Pinky and Blinky.  Each of these versions are several days old, and are in progress--the data contained within should not be posted into sde.default.  Through python, I create a fourth version, Sue, and make edits.  I want to reconcile with default and post only this version to default without incorporating any of the unfinished edits from Inky, Pinky, or Blinky.  Afterwards, I want to delete Sue after posting. 

1) is this possible?

2) if so, what am I doing wrong?

arcpy.ReconcileVersions_management(input_database = connection_to_edit_version,
                                   reconcile_mode = "ALL_VERSIONS", # or BLOCKING_VERSIONS
                                   target_version = parent_version,  # default
                                   edit_versions = [edit_version],  # sue, in a list by herself
                                   abort_if_conflicts = "ABORT_CONFLICTS",
                                   with_post = "POST",
                                   with_delete = "DELETE_VERSION",
                                   out_log = reclog)

[DavidPersson]

Hi, xkcd: Wisdom of the Ancients  , as I was about to ask the same thing (and it seems I might be thinking about this in the wrong fashion then due to limited understanding), but in Reconcile Versions—Help | ArcGIS Desktop  , has optional parameters for edit version and target version and an obligatory parameter for reconcile mode (all versions or blocking versions). The page says "After running the reconcile process successfully with the ALL_VERSIONS option, all versions in the geodatabase will appear the same."

Is there a way to python script one edit version to reconcile and post with&to its parent sde.default? Just like the OP we have several edit versions under sde.default that are intermittently reconciled and posted to default; I'd like to script a reconcile & post as it would happen in a session in ArcMap, where upon reconciling changes to default would end up in my edit versions edit session and then a post would put my changes in its parent sde.default. I don't want for all versions to suddenly look the same, that would be a disaster.

So I'm probably thinking about versioning or this tool slightly wrong and hope someone out here knows better? : )

[MattFrancis]

I wish I could say that in all the intervening years I have gained a better understanding of the ReconcileVersions_management tool, but I have not.  Code I wrote just last month looks nearly identical to the code in the OP. 

I read the same thing, "After running the reconcile process successfully with the ALL_VERSIONS option, all versions in the geodatabase will appear the same." but that doesn't make sense, or my understanding of versioning is all wrong too.  Reconciling pushes changes from SDE.DEFAULT into the child version(s).  If there are no conflicts, there is not a problem--new features just pop up into the child version.  If there are conflicts, we panic and abort or resolve the conflict automatically either in favor of the parent or the child.  Conflicts aside, the child version still has it's unique edits until it gets posted--that statement just doesn't hold water.

Now, regarding reconcile_mode arguments, ALL_VERSIONS or BLOCKING_VERSIONS...  I suspect this parameter gets more useful if your version tree has child-of-a-child versions.  Our tree does not look like that, and where I've deployed this code, I only have one version.  So, take all this with a grain of salt and test, test, test.  But in the doc:

"ALL_VERSIONS —Reconciles edit versions with the target version. This is the default."  I take this to mean "All the versions in the list, [edit_versions] will be reconciled."  If you have children of children, and do not include them in [edit_versions], using the BLOCKING_VERSIONS parameter will reconcile them too, considering the reconcile order.

Again, it doesn't make sense that every version in the geodatabase will be reconciled, nor does it make sense that after the reconcile process, all versions will be identical.  I think we have encountered erroneous documentation, and a parameter value that is misleading.

[DavidPersson]

Hey, thanks for your reply : )

I tested some on a new enterprise geodatabase created for the purpose..two public versions from parent: sde_default, edit both, save, do not reconcile or post in ArcMap, then run the below and my test version "davids_version" is posted to sde_default and the other version remains unchanged. I shall dare to do it on the main database now I think, for after all, we are in agreement that this is how it should be and not necessarily how the ESRI documentation in part appears to suggest that it goes. Will try to send some feedback on said documentation.

                                    "ALL_VERSIONS",

                                    "SDE.Default",

                                    ["\"AD-user\".davids_version"],

                                    "LOCK_ACQUIRED",

                                    "ABORT_CONFLICTS",

                                    "BY_OBJECT",

                                    "FAVOR_EDIT_VERSION",

                                    "POST",

                                    "KEEP_VERSION",

[Kathleen_Crombez]

I realize this is an old post... but this seems to have always worked in the past on traditional versioning. We currently have no choice but to use branched versioning in the parcel fabric.

We recently hired a new employee and want to have his edit version QC'd prior to posting his edits to default. Yesterday he made some edits and even though his version was not included in the list of edit versions, his edits were posted to default anyhow.

I use the arcpy.GetMessages(0) to get the reconcile and post messages directly after arcpy.management.ReconcileVersions and the version is not listed in the messages. But the edits were definitely posted to default regardless of it not being included in the edit versions list.

Is this possibly a bug in branch versioning?