Enterprise geodatabase versioned view necessary?

[Jay_Gregory]

I'm getting some strange behavior when enabling a enterprise geodatabase feature class for versioning to support distributed collaboration.  If I use python and arcpy to enable traditional versioning and global ids 

arcpy.management.RegisterAsVersioned(source_table)
arcpy.management.AddGlobalIDs(source_table)

 I get an additional table in my enterprise geodatabase - the same name as my source table with _evw appended (mytablename and mytablename_evw for example).  

However, if I use ArcGIS Pro catalog pane to do the same thing - register as versioned and add global ids, this evw table is not created. 

My question is is this evw table required if all I am using versioning for is to support distributed collaboration with ArcGIS Online.  I'm not even enabling any feature services for editing - just sync

[MarceloMarques]

ArcGIS Desktop ArcMap/ArcCatalog - _evw is not a table but a view in the database, the view gets created when you register a geodatabase table or featureclass as traditional versioning, the _evw view is created to support workflows that require to edit the geodatabase data via SQL statements.
What is a versioned view?—ArcMap | Documentation (arcgis.com)

ArcGIS Pro - works with "traditional versioning" and when you register as traditional version the "_evw" view shall be automatically created as well, if it is not then please record the step by step to reproduce the issue and open a ticket with Esri Technical Support to investigate further, it might have to do with the fact that you are using arcpy to do this, on the other hand try to enable traditional versioning direct using the Pro dialog, it shall create the _evw view.

ArcGIS Pro now offer a different versioning implementation called "branch versioning" to better support more modern workflows with feature services.

Overview of versioning—ArcGIS Pro | Documentation

Caveat, Branch Versioning does not create a _evw view, and it does not support to edit the geodatabase data via SQL, all the editing needs to be done via REST calls.

I hope this helps to clarify your question.

[Jay_Gregory]

Thank you @MarceloMarques - I'm curious which versioning I should use in order to _only_ support sync capabilities in my feature services - for distributed collaboration with arcgis online.

https://community.esri.com/t5/arcgis-enterprise-questions/minimum-enterprise-geodatabase-table-confi...

Thanks!

[DavidSolari]

If all you care about is sync capabilities, enabling Archiving will allow that without having to deal with version management. You can also use Branch Versioning and never create any child versions, this is roughly comparable to classic archiving. In my experience, either do archiving/traditional versioning for every item in your database or use branch versioning for everything, trying to mix the old and new methods leads to compatibility corner cases.

[MarceloMarques]

I suggest going with "Branch Versioning" unless you need some functionality that only "Traditional Versioning" can offer, but "Branch Versioning is the more modern feature.

About your other question.
Truncate Table (Data Management)—ArcGIS Pro | Documentation

• Versioned data is not supported as input. Data must be unregistered as versioned before the tool will run successfully.

These other links might also help.
Configure a map service—ArcGIS Pro | Documentation
Prepare data for use in offline feature services—ArcGIS Pro | Documentation
Enable layers for offline mapping—Portal for ArcGIS | Documentation for ArcGIS Enterprise

Support Services: Feature Service Sync | Esri Training Web Course

Support Services: Perform a Feature Service Sync Manually Via the REST Endpoint | Esri Training Docu...

Support Services: Deploying and Using ArcGIS Enterprise Services | Esri Training Web Course