ArcGIS Enterprise 10.9.1: Why the “archiving” option is compulsory enabled when working with branch versioned feature class?

[JamalNUMAN]

ArcGIS Enterprise 10.9.1: Why the “archiving” option is compulsory when working with branch versioned feature class?

I couldn’t figure out why “archiving” option is compulsory enabled when working with branch versioned feature class. The database will get fat with this option

[ChristopherCounsell]

Archiving must be disabled when registering the dataset as branched versioned. 

When you register the dataset as branched versioned, archiving is enabled to allow the ability to track historical edits for insert, update and delete operations.

Register a dataset as branch versioned—ArcGIS Pro | Documentation

Please don't forget the kudos 🙂

[JamalNUMAN]

What I meant here is that once the branch option is selected, then the “archiving” option is selected by default.

Is there a way to select the branch option without having the “archiving” option enabled?

[ChristopherCounsell]

I would assume not. Archiving is identified as required for tracking historical edits in the documentation. It's likely a core part of the branched versioning capability. Ratified by it being turned on, in the documentation, and greyed out - they've clearly set it up this way.

[JamalNUMAN]

This is exactly my question. Then why it’s mandatory to have the “archiving” and “editor tracking” selected and grayed out by default? Doesn’t that cause the data to get dramatically fat?

[ChristopherCounsell]

As part of registering a dataset as branched versioned, ArcGIS will set up the necessary data structure and functionality to provide the capability. It moves some of the traditional database elements to be managed at a service level.

I can't see any publicly discussed issues tied to branch versioning archiving. I also understand you are not encountering any currently. Esri has indicated that this approach improves performance.

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

Branch versioning is based on a temporal model which archives edits in a single table that does not need to be compressed, eliminating the performance hits sometimes experienced with traditional versioning. Since branch versioning uses this model, you can now gain all the benefits of archiving without the creation of an additional class. These benefits are realized through a change in design which makes every edit operation an insert behind the scenes allowing a history of your edits (including deletes) to be saved. This provides the ability to perform undo/redo throughout the life of an edit session.

Might recommend taking a look at one of the Esri Dev summit videos. They typically go into more depth and discussion.

https://www.youtube.com/watch?v=Ln0shBwhvaU

[JamalNUMAN]

It would be great if we are gaining more functionalities\capabilities with the branch technology without losing performance or having the data got fat. We will be putting it into operation to test the performance and the data size.

Have you any idea regarding how the size of data grows as the “archiving” is enabled with the branch technology or if there is any clue with respect to the difference between publishing the data stored in file geodatabase or branched enterprise geodatabase?