Branch Versioning Best Practices

[Brian_McLeer]

We are starting to migrate our enterprise database from traditional to branch versioning. The recommended SDE admin workflow (link below) for traditional versioning is to delete \ create versions after editing is complete on a version. At our organization, we reconcile\post, delete versions, compress, rebuild indexes, analyze, create versions via nightly Python routines.

With migrating to branch versioning, compress is no longer needed, and you cannot rebuild indexes (indices?) on branch versioned data. 

My question for the community is it still necessary to delete\create branch versions on a daily schedule after an editor has completed edits for the day? Or is this becoming obsolete, such as compressing the database is as ESRI recommends migrating to branch versioning. 

https://desktop.arcgis.com/en/arcmap/10.3/manage-data/geodatabases/recommended-version-administratio...

[JoeBorgione]

We've done some testing with a cloud based enterprise gdb with branch versioning, and versions don't seem to play such a big role like traditional versioning.  We decided that versions can either stay or be deleted at the user's discretion.  My suggestion is you set up a test environment for yourselves and see if leaving them or deleting them has any impact either way on performance.

We think branch versioning rules while traditional versioning drools.... (Please feel free to quote me)

[Steve_Salas]

@Brian_McLeer " you cannot rebuild indexes "  - it seems like that would be very important as more records accumulate in the table as edits occur.  Did you attempt this with the feature service stopped?  I would think if the service was still running there would be a lock (sorry, haven't tried it... just beginning to look at this new stuff).

[JustinMuise]

Hi Brian,

You are correct - the notion of having to delete your version after you have posted your edits to Default is not applicable to Branch Versioning. With Traditional Versioning, this workflow was recommended as your version could hold state locks which could prevent a good compress. Since Branch Versioning was built in a manner that eliminates the requirement to compress, so does the requirement to delete your version. However, deleting versions which are no longer used by users is always a good practice!

Hope this helps!

Justin