Branch Versioning vs Traditional

[Anonymous User]

Branch is still new and I'm struggling to understand this concept. We are deploying a whole new enterprise setup. We have data that is edited in a SQL database that we want to publish to Portal and have two-way editing. I've made progress on how this works with traditional versions and publishing services to Server.

Upon reading some documentation that attribute rules (which we hope to implement) can be carried forward to feature services, but only if the database is branch versioned. However, Branch versioning is service based and not database based? We can have attribute rules in a traditional versioned environment but those won't work on the service side?

So how do we have a mixed environment? How can we maintain data in a SQL database in Pro with direct editing and also have a branch versioned database to do certain editing with services?

So if we branch version, we can't edit the data in SQL? It HAS to be published as a service to Portal and edited that way? How is this "better"? What if portal goes down, or server, or something with anything in between? We can't directly edit that data without Server and Portal running? I'm not 100% all in on editing services - to me it's not this great new thing that Esri says it is (we've had WAY to many issues editing services in AGO). Is there no way to have a branch versioned database and still edit data in SQL as we've always done?

Why is this so complicated?

[RobertBorchert]

We simply have a single version on our data that can be field or office edited.  Editors just need to be aware that if someone edits something they just changed it will accept the last entry saved as the current.

[Brian_Wilson]

I am testing Branch Versioning now and it works, but so did the Old Versioning system.

I am asking the same questions. It's interesting that there has been so little reaction to this posting. So far to me it seems like Esri went in the wrong direction.

Their implementation of Branch Versioning is called a "tightly coupled system". In computer science tight coupling is regarded as bad.  With Old Versioning everything lived in the database. Now I need to publish the data through Portal and Server, and I have to use one version of ArcGIS Pro tied to one version of ArcGIS Enterprise. Many more moving parts!

I am looking for a response from Esri that explain why Branch Versioning is better FOR MY USERS. I can understand that it is better for Esri because they get more lock in and more strict requirements for licensing, and maybe more server licenses and we might have to license more CPUs on our server to cope with release incompatibilities and the resources required to run a separate, dedicated server instances for each branch versioned feature services.

How is it better for USERS?

Telling me it's a Service Oriented Architecture is just a buzz phrase. That does not mean it's better.

Telling me it means I can manage user access through Portal also means nothing for me because I already have complete control over who can access SQL Server.

I need to make a case for it, and the case has to be stronger than "Esri is making us do it" to be convincing.

[Scott_Tansley]

I think we tend to look at things as black or white.  In this case, we need to use Branch-Versioning or Traditional Versioning.  It's simply not true.  We need to look at each dataset as a different use case and determine which is the best approach.  

The clear win from using branch versioning is performance.  Traditional versioning uses a multitude of layers, views and stored-procs to make a single dataset work.  It's computationally expensive and makes editing slow, and has a wealth of overheads like regular compression activities.  Branch versioning is all in one table.  It's actually how many other IT systems have dealt with versioning for years.  It works in a web environment well and will be great for the emerging use-cases of parcel fabrics and Utility Network Models.  Personally, I'm excited about Branch Versioning and what it will be able to do.  I'm also excited about the performance that it will bring to web workflows.

Esri is putting a lot of development into the use of UNME and Parcel Fabrics (etc) and needs the database team to develop branch versioning to support all of that.  So just like we see things that are in ArcGIS Pro that aren't in ArcMap (and never will be), we have to accept that things like Attribute Calculations (etc) won't be in traditional versioning and may not be for a while (or ever).

But none of that precludes us from using old-versioning and branch versioning in a hybrid model and using the best of both to support the requirements for that given dataset.  

Sorry, just my view on it.  Very few of my clients are using Branch Versioning yet, but as it breaks more and more away from ArcPro and finds it ways into native and web clients then I think adoption will go up.

Oh, and I believe you can have unversioned workflows with attribute rules and the like.  I've seen some organisations do desktop editing like that and use that database as 'staging' before moving the data to 'production', yes it means more overhead, but they liked the separation of stage ->  production -> publish

[Brian_Wilson]

Thanks @Scott_Tansley 

Today I was trying to make a case for Branch Versions being accessible directly from web and webmaps but could not find any examples of that. I need to be able to demonstrate this, not just make airy claims about what it might be good for someday.

This afternoon I found this and am looking at it, it says Branch Versioning is included in Experience Builder: https://www.esri.com/arcgis-blog/products/experience-builder/announcements/whats-new-in-arcgis-exper...

Clearly from your comments I need to do some performance evaluations. If Branch Versioning really is faster that would make a big difference, and it surprises me Esri does not tout that. (Not that I've seen anyway.) 

We want to see our cartographers using Parcel Fabric (and ArcGIS Pro!) so we have to get Branch Versioning going, it's not optional for that but I need to convince people that migrating other datasets is worth the bother.

Eventually we have several people who run a few simple workflows in Arcmap, we could probably migrate from Arcmap to web apps and from concurrent licenses to Portal editors, but I want versioning of some kind for this.

[Scott_Tansley]

I hear you.  Yes, once again the Web App Builder was JavaScript v3.x based (I belive with elemts of 4.x).  The work to get it working in a web environment meant it had to be developed in the 4.x libraries and therefore 4.x.  I expect to see more emerge over coming releases.  I'm also hoping it's going to be more represented in the runtime based clients like Field Apps.

The performance thing will be interesting.  Given that you're editing through the web, if you're in an outpost with a cronky bit of copper between you and the server then it won't be fast, but neither would versioned editing in a two-tier environment!  If it's all in-house and fibred up you should be good.  I havent' benchmarked, which is something I need to do for myself and understand these workflows.

Good luck with your research.  It is a pain-point, I agree, but no different to adopting any new technology.

All the best, and thanks for a really interesting discussion.