topic Re: Blog discussion - branch versioning in Geodatabase Questions

Blog discussion - branch versioning

MelissaJarman — Tue, 20 Aug 2019 17:58:17 GMT

A series of blogs are released that discuss branch versioning in ArcGIS Pro / ArcGIS Enterprise. This discussion is for questions that are directly related to content/concepts included in these blogs.

Branch versioning blogs:

To branch or Not to Branch - An Introduction
Branch Versioning: Setting the Stage - Configuration and publishing
Editing and Administration with Branch Versioning - It's Showtime! - Basic editing and administration

Enterprise GIS‌ ArcGIS Enterprise

Re: Blog discussion - branch versioning

HéctorMeléndez — Tue, 27 Aug 2019 06:21:10 GMT

Hi. I would really like a blog about using branch version with the apps for the field. It is not clear to me if a feature service publishes from a branch version would be supported by existing field apps like Collector or Survey123 or web applications like Web App Builder.Melissa Jarman

Re: Blog discussion - branch versioning

MelissaJarman — Thu, 12 Sep 2019 14:20:29 GMT

Thanks for the suggestion Hector - perhaps in the future there will be blogs about workflows with using branch versioning with some of our apps.

While not in a blog format, there was a thread that discussed this on geonet:

https://community.esri.com/thread/209498-taking-branch-versioned-data-offline-with-collector

Re: Blog discussion - branch versioning

Brooks_Wilson — Thu, 12 Sep 2019 22:20:10 GMT

Ditto what Hector said. It would be great to see examples of each of the edits listed at the first link, "Data published and versioned through the ArcGIS Enterprise portal allows for edits to be contributed from smartphones, web applications, third-party apps, and even automated scripts using the REST API."- An Introduction to Branch Versioning

I would also like to see a blog on how to manage branch versioning in a distributed editing environment. How do you control which users can edit a branch service? Do you need to create a separate non editing service for other users to view the data? Can different people create services, then be able to post only versions created from their service? Can a service ownership be transferred and that new user be able to control the version management?

Re: Blog discussion - branch versioning

HéctorMeléndez — Wed, 02 Oct 2019 01:20:49 GMT

It would be nice to have the blog though. Details about how multiple editors or sync operations would lock the default version or if it would scale better than traditional versioning. Just an official response from Esri if branch versioning is adequate for field collection and web editing workflows or if there is still some development to be done before we can start migrating some of our traditional versioning workflows.

Thanks.

Re: Blog discussion - branch versioning

JohnAnderson1 — Thu, 02 Apr 2020 22:48:58 GMT

Does Esri have plans to support Topology and Network Datasets with Branch Versioning? If so, when? My organisation would like to migrate our data editing systems to Branch Versioning but we can't do so until this functionality is made available.

Re: Blog discussion - branch versioning

DanMcCoy1 — Wed, 15 Jul 2020 21:25:00 GMT

this might answer the question about topology...
What’s New in the Geodatabase at ArcGIS Pro 2.6

Re: Blog discussion - branch versioning

JoeBorgione — Wed, 15 Jul 2020 21:29:13 GMT

Just now wrapping up a UC session on branch versioning (7/15, 3:30 mountain time). Cool stuff to be sure.

Re: Blog discussion - branch versioning

MelissaJarman — Thu, 16 Jul 2020 14:57:30 GMT

Our teams worked hard to add support for branch versioned topology this release. This work was done by the geodatabase and feature service teams to support a new topology layer for web feature layers and enabling many of the validation workflows through the gp tool and error inspector via services.

We currently don't have near term plans for implementing branch versioning for network datasets.

Here is a new blog with some highlights of new geodatabase functionality for 2.6/10.8.1 -

What's New in the Geodatabase at ArcGIS Pro 2.6

Re: Blog discussion - branch versioning

JohnAnderson1 — Mon, 20 Jul 2020 00:32:44 GMT

Thank you for the update Melissa and Dan. That is great news!

Re: Blog discussion - branch versioning

InvenergyGIS_User — Tue, 21 Jul 2020 18:28:23 GMT

What did you learn about how editors lock the version/service? How does this work with a field app with multiple concurrent users? Did they share any new resources?

Re: Blog discussion - branch versioning

SeanQuarnstrom1 — Mon, 27 Jul 2020 22:45:15 GMT

How can you edit / add to a feature service's Fields / Domains on branch versioned published datasets?

Re: Blog discussion - branch versioning

MelissaJarman — Tue, 28 Jul 2020 14:48:09 GMT

You will still be able to perform schema modifications when connected directly to the database connection. This will be performed as the data owner, just as you would for any other registration type.

Re: Blog discussion - branch versioning

AndrewQuee — Mon, 07 Sep 2020 06:34:26 GMT

The move to a flatter versioning system is welcome because it almost all cases we have no requirement to have versions on versions on a version. There's change required to production data in multi-user editing, and that's it, so just the one child version per change (which only lasts as long as the edit lifetime) is all we need. In fact unraveling accidental grandchild versions is the only thing we do with the current multiple layer versioning system.

The move to a service-oriented system is also welcome and a great innovation, allowing much greater flexibility, scope and wealth of applications working with enterprise data across the internet, especially important while staff and clients can both be working from home during COVID-19.

One thing that is a concern though is we currently allow users to create, edit, reconcile and post their versions to DEFAULT (we use customisations to prevent direct editing of DEFAULT) but this seems no longer possible unless we make them feature layer owners or portal administrators.

We'd like to retain the efficiency of self-managed editing with a minimum administration overhead with protected DEFAULT version. But it's inadvisable leave it unprotected or to make all users of the service Owners and unsafe to make them all Portal Adminstrators just to be able to reconcile and post to DEFAULT. We'd also like to remain as close to COTS as possible to deliver development and support efficiencies.

What would be ideal for our workflow is if in Enterprise permission can be given to allow classes of users the ability to create, reconcile and post their versions to a protected DEFAULT branch version, but not edit the default version directly.

Re: Blog discussion - branch versioning

MelissaJarman — Tue, 08 Sep 2020 15:31:30 GMT

Thanks for your feedback. With the release of 10.8.1 there is a new portal privilege that will allow you to create custom roles for users that need to serve as version administrators for services with the Version Management capability. This will allow you to grant permissions to perform these version administration tasks for branch versioned datasets via services without having to be the service owner or having to be an administrator.

Under Version Management, you can read about the Manage all privilege.

User types, roles, and privileges—Portal for ArcGIS | Documentation for ArcGIS Enterprise

Currently, this portal privilege is an all-encompassing privilege that is not separated into individual tasks:

Your comment about being able to post to a protected default while not being able to directly edit the protected default version is interesting. This is a request we have heard from others users as well in discussion. Please feel free to elaborate on what workflow this would help facilitate.

Re: Blog discussion - branch versioning

JohnAnderson1 — Wed, 09 Sep 2020 05:05:22 GMT

Hi Melissa Jarman‌ I work with Andrew Quee‌ and I can elaborate on the topic of workflows. Essentially we want to give editors in our organisation access to creating child versions from DEFAULT, editing versions, and then reconciling and posting, but we don't want to allow editors to edit the DEFAULT directly. This is because we don't want editors to accidentally edit DEFAULT, but we do want to give them the flexibility to edit data using long transactions and to Post edits to DEFAULT from their child version. To achieve this in the past we built a custom ArcMap Editor extension which listened to Editor Events such as Start Editing and raised an error if the workspace was the DEFAULT version. The disadvantages with this option is that it requires coding/customisation and the user needs to editing in ArcMap and have the Add-In installed. It would be helpful if Portal and ArcGIS Pro could be configured to achieve this without custom code.

To elaborate a step further, our old ArcMap workflows also required that editors validate any new or modified features (that were created/modified in the child version) before they post to DEFAULT. We have also enforced this with code and using Data Reviewer, but it was tricky because there is no ArcObjects API for Data Reviewer - we had to use a combination of ArcObjects, Python, and Data Reviewer geoprocessing tasks. So yeah, an additional configuration in Portal / ArcGIS Pro that enforced data validation prior to version posting would also be very useful!

We are currently investigating ArcGIS Pro Tasks and Workflow Manager to see if they can provide a better solution (than coding), however sometimes the out-of-the-box options end up requiring more clicks of the mouse and are less efficient.

Re: Blog discussion - branch versioning

MelissaJarman — Wed, 09 Sep 2020 23:42:35 GMT

Thanks for the additional information John! This helps to understand your workflows and it is just a simple preference that users not directly edit default. You do trust these same users to post to default, but would also prefer to add additional requirements prior to post such as validation.

We currently have validation attribute rules that can be evaluated via services, but there is currently not a way to force validation to be run before posting. Until a solution like this is available out of the box....

You could use the ArcGIS Pro SDK to remove the default Post button and replace it with custom code the runs validation first.

Re: Blog discussion - branch versioning

AndrewQuee — Fri, 30 Oct 2020 02:51:17 GMT

Yes, this is exactly what we are doing now in Desktop and Pro business systems. We were hoping to return to somehting more COTS-like and reduce development overheads is all. Thanks for the clarification.

Re: Blog discussion - branch versioning

SeanRedar — Thu, 07 Jan 2021 18:03:37 GMT

When setting up for branch versioning do you generally recommend using headless admin accounts for the both the RDBMS and portal sides? The documentation seems to indicate that all access control rest in the Portal side.

Re: Blog discussion - branch versioning

Kathleen_Crombez — Thu, 22 Jul 2021 14:56:06 GMT

Branch versioning makes me want to retire early also!

ESRI kept saying it is so much easier to administer branch versioned data. But as a long time database administrator, I am finding this to be the exact opposite. Not to mention SQL views are now a serious pain to accomplish without creating a function to extract a versioned view of the default user.

Who ever thought it was a good idea to edit through a service instead of directly through the database and create this versioning scheme where the tables grow exponentially instead of compressing back down after a reconcile and post has lost touch with their user base.

Yes, let's make sure every administrator has to rewrite their simplified code and make them learn a new API just to roll up edits. It's ridiculous!