Select to view content in your preferred language

Common Practice of Versioning

11-30-2016 08:31 AM
Occasional Contributor II

Hello GeoNet Community,

I am seeking for suggestions of a good use of versioning please.  I am wondering if it is a common practice to version all feature classes (~100+ layers) in a geodatabase?  But only some of them will be edited regularly, the others might be edited once a year.  Also, if 90% of the time, only one editor would edit the layers, would it still be a good practice to version the layers just in case of the 10% of the time?  

Thank you,


0 Kudos
13 Replies
Esri Esteemed Contributor

Hi Emily,

In addition to some of the good responses already, you might find this Technical whitepaper useful. While it is a bit old, its concepts are still good and applicable to versioned data management in an enterprise geodatabase:

Versioning Workflows Technical whitepaper

Hope this helps,

Occasional Contributor II

Thank you, Derek!  You're always famous at UC! 

0 Kudos
MVP Emeritus

Also keep in mind that although the database is registered as versioned, that doesn't mean you always have to have child versions. If 90% of the time none of the files are needing edits, you can set up the security as Robert discussed, basically having it be read only for all but SDE account and/or the owner. Then when you are getting ready to make changes, create a version (only takes a few seconds) giving your designated edit the rights to edit. Do your necessary reviews of the data, and when ready to publish,  do a reconcile and post so others will see the updates from default. If you know that it will be a while before you need to make anymore changes, you can always delete the child version after the reconcile/post and after an admin compress, you may even get back to state zero.

Personally, I would always recommend making changes thru a child version and not the default because it gives you the chance to reject conflicts if needed. That is not to say that I haven't made a quick, simple change directly to the default (for example a change to an attribute).

Also, take advantage of creating an historical markers that can basically show a virtual cooy of the database status at the time you made the connection.

Occasional Contributor II

Thank you, Rebecca. This might be a good workflow for me.  

0 Kudos