nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Traditional & Branch Versioning in the same database

Anonymous User

Can we use both Traditional & Branch Versioning in the same enterprise database? I think the answer is yes, but I wonder how Reconcile/Posting would work. If you Reconcile/Post through a database connections would that only work for the Traditional features, and then Reconcile/Post through the service would only work for the Branch features? There wouldn't be any kind of conflict?

Also, since Replication doesn't work with Branch Versioning, has anyone found a good way to synchronize a Branched Versioned dataset to another enterprise database?

Find more posts tagged with

Geodatabase Administration

Versioning

Geodatabase Replication

Accepted answers

All comments

George_Thompson

Yes, Branch and Traditional versioning can be used in the same enterprise geodatabase. The features classes can only participate in one or the other, NOT both.

You would reconcile / post as normal, there would not be any conflict as they do not share feature classes that participate.

As for the replication, you can edit the branch versioned data via the web as it is a service based architecture (Web GIS). Is there a reason that you would need to replicate with this model?

Here are some great blogs to review:

https://www.esri.com/arcgis-blog/products/arcgis-enterprise/data-management/to-branch-or-not-to-branch/

https://www.esri.com/arcgis-blog/products/arcgis-enterprise/data-management/branch-versioning-setting-the-stage/

https://www.esri.com/arcgis-blog/products/arcgis-pro/data-management/version-administrator-for-branch-versioned-data/

https://community.esri.com/t5/geodatabase-questions/blog-discussion-branch-versioning/td-p/835462

Let us know if you have any other questions.

Anonymous User

Ok, thank you for confirming the versioning scenarios.

We want to replicate our data because we are creating a dev environment to run along side our production environment. Running both traditional and branching versioning isn't an issue, except that we want to replicate our Water UN. Which it seems like won't be possible.

George_Thompson

Many people just use DB backup / restore to "refresh" data in DEV from PROD.

You should be able to use branch versioning to edit / "share" your UN data.

Anonymous User

We want to Replicate our UN data onto a different database in order to test our new workflows and troubleshoot, not just simply sharing. We need to keep these databases separate but in sync.

It would be very useful to be able to replicate branch versioned data.

SeanRedar

Question 1- is branch versioning available for layers published from a user managed data store? (assuming no).

Question 2 - given I have many feature classes (30+) I would like to publish with branch versioning enabled, is it recommended to publish each layer alone or several together, like in the case with have a particular business line that has many feature classes.

MMBR

Question 1- is branch versioning available for layers published from a user managed data store? (assuming no).

Answer: No, you must have an Enterprise Geodatabase - Oracle, SQL Server, PostreSQL.

Answer: it depends on the size of each featureclass and the business case that you are trying to solve, I would group them by editing workflow and then decide if shall break into subgroups.

Scott_Wolfskill

I am in a similar situation, but with enterprise data being shared with a client via a feature service. We are utilizing branch verisioning to manage edits on our side and had originally envisioned having two way editing using a distributed collaboration between our enterprise portals. However, our client is on an earlier version of Server and cannot enter a two way editing relationship at this time. We instead passed the portal service through to AGOL to share via a partnered collaboration, which has been working well in a read only capacity.

The client still has the desire to edit the data and I had hoped a check out could be created from default so they could complete data edits and return them to us for check in. This is apparently not possible now, but it would be great to see this kind of functionality in the future. For now we are handling all edits for the client, which is acceptable, but it is limiting, and we would like to find a better solution for the future.

Does this group have any suggestions for this use case or see anything I am missing here?

MMBR

1. Geodatabase Replication is not an option because you are using Pro Branch Versioning

Prepare data for replication—ArcGIS Pro | Documentation

Note: Branch versioned data and data registered with traditional versioning that uses the option to move edits to base are not supported with geodatabase replication in ArcGIS Pro.

2. Geodata service and Take data offline with feature service sync capability

This might be an option for you. Read more in the links below.

Geodata service—ArcGIS Server | Documentation for ArcGIS Enterprise

Take data offline with feature service sync capability

Introduction to distributed data—ArcGIS Pro | Documentation

3. FME Workbench + FME Server

and/or

ArcGIS Data Interoperability + Model Builder + ArcGIS Server Geoprocessing Service

you can customize and create your own tool to synchronize the data, using out of the box functionality.

I hope this helps.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.