Getting to Know Branch Versioning

[Music] hello everyone my name is justin muse and today i will be providing you with an overview of branded versioning helping me today are john derose and annie sassadar who will be helping me with demoing some of the functionality and answering any questions you may have briefly branched versioning is our new versioning type which takes advantage of our service based architecture leveraging version capabilities to the web this is something that is unique to branch versioning and that is not possible with traditional versioning we'll talk about this new architecture along with other advantages and important details so without further ado let's take a closer look into what we will be covering today i will be talking about a summary of versioning in the context of arcgis what branch versioning is and how it differs from traditional versioning and the benefits and the best practices to use brand versioning after reviewing some general information on branch versioning we'll jump into a variety of demos which illustrate how to prepare and publish with branch version data we'll dive into some editing workflows and we'll look at version administration with branch versioning we'll finish the presentation with what to expect in the arcgis pro 2.6 and enterprise 10.8.1 release and will be available to answer questions at the end of the presentation so be sure to stay tuned until the end of the presentation now let's get into it first a quick summary of versioning in general versioning is esri's long transaction model it is the architecture that supports undo and redo and editing and isolation within the arcgis framework this functionality is hidden behind what we call versions a version is a snapshot or representation of your data at a given state in your database and edits for these versions are managed through a variety of system tables how many of you are currently using branch versioning if you are you are likely aware that branch version behaves much like traditional versioning and that its main difference is that it uses a service based architecture it is its own registration type meaning it follows a new data model and has its own requirements before registering the data as branch versioned it supports multi-user editing and long transactions via services where most of the version administration is completed through the version management service the version management service is created while publishing your data to an enterprise portal although both branch versioning and traditional versioning manage their versions through a series of system tables both do so differently branch versioning follows a temporal insert only model where all edits are maintained in a single table meanwhile traditional versioning manages edits using delta tables and joins them with other system tables to determine how to represent the data within a given version because of branch versioning's single table model you will see additional fields added to the business table to manage the edits between versions after registering your data as versioned these fields include the gdp branch id field used to track which version the edit belongs to the gdp from date field used to track when the edit was made the gdp is delete field used to track whether the feature was deleted the gdp deleted at field used to track when the edit was deleted the gdp deleted by field used to track who deleted the feature and the gdb archive oid field used as the unique identifier for the table because of this table structure branch versioning feature classes natively support archiving meaning you do not need to additionally enable archiving on your branded version feature classes because branch version uses a service based architecture there are a few caveats which should be pointed out that is that versions are bound to a service meaning if there are multiple feature services referencing the same database or even the same data versions from each service are not aware of each other more specifically if you create a version in service 1 you will not see that version in service 2. next we're going to jump to some benefits of implementing branch versioning there are many benefits of using versioning in general such as isolated editing and mobility to undo and redo however i want to go over what branch version offers in comparison to traditional versioning one of the main driving factors for building branch versioning was to support versioning in a services environment because of this you get the power of rest giving you access to the data without requiring direct access to the database however there are a variety of other optimizations which complement this capability for example as we discussed on the previous slide branch versioning natively supports archiving and therefore no longer requires you to enable archiving on the data manually french versioning leverages the benefit provided by editor tracking with an enhancement to also track deletes which is currently not supported with any other registration type queries are optimized because of the streamlined table structure that we discussed in the previous slides in traditional versioning when editing default you are internally editing a version and then reconciling posting with branch versioning your editing default directly increasing throughput how many of you have got into a scenario where edits were pinning a state when using traditional versioning traditional versioning required a compress to push edits to the base table which pinned the states preventing simultaneous editing the post operation was also serialized limiting users to edit the default version while the post operation was occurring both of these examples do not hold true for branch versioning where compressing the database is no longer required and editing the default version while another user is posting their edits is not blocked this promotes a 24-hour system as there is no required downtime branch versioning promotes simpler administration it uses a flat tree structure which avoids pinning any states and makes it easier to manage your versions because of the new design compressing the database like we just mentioned is no longer required therefore that is a task that the geodatabase administrator no longer needs to complete this also avoids the requirement to delete versions after they are posted a common best practice used for traditional versioning to again void pinning states one of the biggest requests received was persisted conflict sessions with branch versioning conflicts are now persisted across multiple edit sessions with traditional versioning after reconciling your version it is required that you resolve all your conflicts in the same edit session this is troublesome for example in scenarios in which you reconciled at the end of the day and realize halfway that you cannot finish reviewing your conflicts before leaving the office this would require you to discard your edits and repeat the process again another time we will illustrate this functionality in a demo later in the presentation furthermore the conflict resolution process is enhanced with the ability to add notes which can be viewed and updated across multiple sessions and users and finally conflicts can be filtered and marked as reviewed making it easier to track and organize the conflicts you already have reviewed one of the most common misconceptions is that users need to move to branch versioning because it is the new versioning technology although i just noted great advantages of using branch versioning and a lot of our platform is moving towards a service based architecture it's important for you to understand that you should choose the model which fits your needs more appropriately that it is more than acceptable to continue to use traditional versioning for example if you want to leverage versioning in the services environment plan on using the utility network or the new parcel fabric or want to use versioning with sap hana you will need to use branch versioning as your registration type as these data models and database platform only support branch versioning if you do not plan on using feature services or if you plan on editing other data sets which do not support branch versioning such as network data sets you will need to use traditional versioning it must be noted that there is no migration pattern between the two versioning types if you plan on moving to branch versioning from existing traditional version data you will have to reconcile and post your versions complete a full compress unregister your data as versioned and then proceed with registering your data as branch versioned all right now i'm going to pass it over to john to give us all our first demo he will be illustrating to us how to prepare and publish our branch version data take it away john thanks justin in this demo we'll take a look at the process of registering your data as branch versioned there are three prerequisites to register your data as branch versioned first the data set must have global ids editor tracking must be enabled and you must be connected to your data using a branch versioning database connection so to start off let's take a look at the process of making these schema changes in this database connection i'm connected to the database as the map user which is the data owner of the aurora data set that we'll be using i'm first going to add global ids by right clicking the aurora feature data set going to manage and then selecting add global ids once that completes we can then proceed with enabling editor tracking by again right clicking the aurora dataset selecting manage and then clicking on enable editor tracking here now that the global id and editor tracking fields have been added we can move forward with registering our data as branch versioned to ensure that we register our data as branch versioned and not using traditional versioning we first need to ensure that we are using a branch versioned database connection to confirm or change this we can right-click the database connection and go to geodatabase connection properties once this dialog is open we need to make sure that the branch radio button is selected for the versioning type with that done we can then click ok to close the dialog and we're ready to register our data as branch versioned to register this data set as versioned i'll right click on the aurora feature data set select manage and then click on register as versioned when that completes we can confirm that the data was registered as branch versioned by viewing the properties for one of the feature classes here we can see the versioning type on the source tab with set to branch it's important to note that once the data is registered as versioned the data is only editable through feature services so we've just demonstrated the steps necessary to register your data as versioned using branch versioning as well as how to prepare this for publishing before we continue there are a few other points i'd like to touch on first consider loading your data before registering it as versioned loading data afterwards must be completed through the service and may be more time consuming it's important also to note that once published permissions are set through the services architecture this means the database administrators are no longer responsible for granting permissions to the data but rather portal administrators control access and permissions by assigning roles to a user's portal identity lastly once the service is published the version management server cannot be disabled this is due to internal dependencies on the server with that said let's take the next step and publish our data to the enterprise portal in this demo we'll go over the process of publishing a feature service with the version management capability in the top right corner of the screen you can see that i'm currently connected to my enterprise portal as the publisher user who has the appropriate privileges to publish data to my portal to begin publishing my data i first need to add my data to a new map as a reminder in the previous step i added global ids enabled editor tracking and registered this feature data set as branch versioned i'll now navigate to my database connection here which has been set up using a branch version database connection right click my data set and choose add to map when publishing branch version data it's important to note that the data must be added to the map for publishing as the data owner with my data added to the map i can proceed with the publishing process by activating the share ribbon i'll then navigate to the web layer command found in the share as group and then select publish web layer from the split option to open the shares web layer geoprocessing tool in this tool under the general tab i'll include some general information for the feature service and give it a name summarize the contents and include any helpful tags to provide metadata when accessed from my portal to enable editing capabilities i need to check the feature check box found here in the layer type section this is a requirement not only to edit your data but also if you want to enable use of the version management server which i'll touch upon more in just a moment but first i want to make sure that i share this service with my organization so let's go back to the version management server when publishing branch version data it's important to ensure we enable the version management capability which is found here in the configuration tab under capabilities enabling version management will create the version management server which is what will allow us to complete versioning tasks everything from creating versions to performing reconcile in post the last requirement we need to set before we publish our data is to make sure we're using a dedicated instance we can do that by going to configure pooling on the configuration tab and ensuring a dedicated instance is set for the instance type with that complete let's analyze the map here we've received an error stating that our layers data source must be registered with the server this is understandable as registering the data with the server is a requirement for branch versioning as a result branch versioning is not supported with hosted feature services i can resolve this error if i right click on it and choose the option to register my data source with the server this will open a dialog to fill out some basic information on the data source i'll give it a title add some tags then i just need to make sure that it shared with my organization i'll then validate my entries and create the data store now that my data has been registered with the server i'll rerun analyze we are still seeing some analyzer warnings these warnings will not prevent publishing but should always be reviewed and addressed for optimization for the purposes of this demo however i'm going to proceed and publish my feature service and then i'll pass it over to justin thanks john now that our data is published i'm going to go over a couple of editing workflows with a feature service that has the version management capability enabled we'll touch a little on editing the default version and illustrate how to connect to and edit a version as seen in the top right corner i'm currently connected to my portal as the editor user on the left in the data sources tab you can see that i am automatically connected to the default version since i just added my data to the map before we change over to a named version to edit i want to demonstrate the user experience editing the default version when its access level is set to protected and we are editing as a non-version administrator user i'm currently in my area of interest and i'm going to attempt to change an attribute on a building i'm going to do this by accessing the edit ribbon selecting the appropriate building and clicking the attributes button to open the attributes pane there have been some proposed changes in this area where the residential buildings are now in mixed use i am therefore going to change the assigned building type you will notice that i received an error on attempting to edit this building attribute this is because the default version is set to protected prohibiting users from editing and making accidental alterations only users with higher privileges which we will illustrate in a future demo can edit and post to the default version where it is set to protected it's important for organizations to determine the appropriate access level of the default version as the default version is typically seen as the most current and accurate state of the data we just briefly demoed editing the default version set to protected as an editor user at face value the experience seems very similar to traditional versioning however there are a couple of concepts that are different the default version does not support the ability to undo and redo when the version management capability is enabled this increases throughput when editing the default version finally the default version supports multiple users reading and editing simultaneously name versions follow a one editor or multiple viewers model this behavior is maintained through shared and exclusive locks which are recorded in the gdp locks table in the underlying dbms i now want to demo editing a version where a user with higher privileges can eventually review my edits and merge them with default let's proceed with editing a version on the data sources tab i'm going to select the default version to enable the versioning contextual tab in this ribbon i can complete a variety of versioning tasks such as managing my versions creating a new version and reconciling and posting i already have a version which i want to use therefore i'm going to click the change version button navigate to the version i want to work with which is my proposal version and click ok when connected to another version the version is illustrated in the data source tab to show which version i'm actively editing like our attempted edit on default i'm going to proceed with changing the building type of a couple of buildings to mix use as well as delete a building which was recently removed from the proposal i'll complete these edits by selecting the appropriate building clicking the attributes button and updating the attribute in the attribute pane for the second building i will follow the same workflow where i am again going to set the building type to mix use as well finally i will delete this last building by selecting the feature and clicking the delete button on the edit tab notice that in the top left corner i can undo and redo my edits this is because we are editing against a named version which uses long transactions during editing edits will also not be committed to my branch until i hit save now that we've completed the edits in our name version we can reconcile to pull edits from default to our version and see if our edits cause any conflicts to reconcile we will select our version in the data source tab activate the version contextual tab and click the reconcile button prior to arcgis pro 2.6 in arcgis enterprise 10.8.1 branch versioning only supported reconciling by defining conflicts by object however in the latest release we now support both defining conflicts by object and by attribute for the purpose of this demo we'll use the option to reconcile by object a dialog popped up after reconciling indicating that there are conflicts this means that the same features were edited in the default version and we need to determine which edits should be used to represent our data accurately so let's look at the conflicts by clicking yes agreeing to open the conflict manager the conflict manager will show all feature classes which have conflicts expanding the results set will divide the conflicts and categories of the conflict type and finally the object ids which are in conflict the conflict display can also be expanded to show the spatial representation of the feature which can be useful in determining geometry changes in this specific case we can see that the building was deleted in my version while the building type attribute was updated in default as an editor it is important that i review these conflicts to confirm that i did not make any mistakes while editing but also to provide notes that could help the version administrator when they complete qa against the version the first edit shows that it was deleted in my version but updated in the default version i recall having a meeting regarding this building where although it was planned to be renovated it was decided to be demolished because it wasn't in good enough condition therefore i'm going to add a note to the version administrator reminding them of the meeting we had by right clicking on the object id and selecting add review note since i am confident with these edits i'm also going to mark this conflict as reviewed the second edit shows that the features was updated in my version with a new building type and deleted in the default version it is possible that this is yet another building that was planned for renovation but did not meet sufficient building standards but i do not recall although i believe my edit is appropriate i will leave it unchanged for the version administrator to review this final edit shows that the conflict is a result of updating the building type in both my version and the default version i recall now that this building was indeed getting reclassified as commercial i can therefore choose to change my feature to reflect the changes made in default by right-clicking the object id and using the replace with target version option again i'm going to mark this conflict as reviewed because i'm confident in my edits one quick feature i would like to point out while we are here is the option to filter reviewed conflicts this allows users to hide conflicts they've already reviewed making it much easier to manage the conflicts especially in scenarios where many conflicts are present now that i've completed reviewing my conflicts i'm going to save my changes and close the conflict manager now that i'm confident with my edits i need to inform a virgin administrator that i'm done with my version and that they need to review my edits i have therefore messaged john to let him know that i would like for him to review my version for john or another version of mercedes to complete the qr process i need to make sure that there are no locks in my version so that they can connect and edit i am therefore going to change to the default version to release my lock other options to release my lock would be to remove the service from the map or simply close the application john can now connect to my version and review my edits back to you john thanks justin in this demo we are going to walk through some common version administration workflows with branch versioning i play the role of one of our version administrators in the organization the version administrator is anyone who has higher level privileges that provide the ability to access manage and edit versions they do not own including the default version no matter the access level in arcgis enterprise 10.8 the version administrator was either the service owner or a portal administrator in arcgis enterprise 10.8.1 we've introduced an additional version management portal privilege called manage all this new privilege can be used to create custom roles that can then be assigned to individual portal users justin let me know that he had finished editing his version and wanted me to review and complete qa for it we are going to review the edits that justin has completed and post them to the default version connected as a user who has been assigned a role with the manage all privilege as you can see here in the top right corner i'm currently connected as the version admin user and i'm working with the same feature service that justin was previously editing to review his changes i'll need to change it to his version i'll do that by right clicking the default version in the contents pane i'll then select change version select the proposal version and click ok justin's proposal version is currently set to private i mention this as a note to illustrate that version administrators can connect to and edit both protected and private versions they don't own as we'll see more of in a moment one of the benefits to using branch versioning is that conflicts are persisted across sessions due to this i can access and open the conflict manager here even though i have not reconciled the version myself so let's open the conflict manager and review justin's edits after just and reconciled there were three conflicts identified even though i'm connecting through a different session in pro i can see the same three conflicts in the conflict manager for one of these conflicts justin left a note for me to review regarding the edit i can review that note by right-clicking the object id here and then clicking edit review note i agree with justin's statement and the edit that he's made so i'm going to leave it as is looking at some of these other conflicts we can see that justin has already reviewed some of them himself the reviewed status of a conflict is also persistent across sessions so we can just like justin did move through these edits and review the changes that were made we can open the conflict display to see the larger context of the geometry change that has been made upon review of this update delete conflict i've decided that the record should be replaced with the default representation of the feature i'll choose the option here to replace with the target version and i'll then mark the conflict as reviewed taking a look at this last edit it looks good to me as well so now that i'm happy with all the edits i'll save them click save all edits here i can close the conflict manager and i'm ready to post my edits since i'm reviewing these conflicts in a named version and some time has passed there may have been additional edits made to the default version as a result i need to first reconcile before the option to post is made available and as there were no conflicts identified i'm going to proceed with posting my version with that complete justin's edits and my changes have been applied to default let's now change back to the default version to look at one last thing in an earlier demo justin illustrated the editing behavior for an editor in an architecture where default was set as protected in this demo i wanted to quickly display the editing behavior on default when connected as a portal user who is also a version administrator at the top right you can see i'm still connected as the version admin continuing in my same area of interest i'm going to attempt to change an attribute on another building i'll do this by accessing the select command on the edit ribbon and then selecting the appropriate building to access the attributes for that feature i'm going to update the building type to commercial and click apply you'll notice two things one that it was successful on a protected default because i have the appropriate permissions as a version administrator and second as seen here in the top left corner save and discard as well as undo redo or disabled this is because edits are applied directly as short transactions which increases throughput when editing the default version let's go back to justin now to recap and hear about the new functionality coming with arcgis pro 2.6 and arcgis enterprise 10.8.1 thanks john that completes the end of our demos and we are fast approaching the end of our presentation so what better way to end than to highlight some of the new functionality coming up in the next release during the demos we talked about the new manage all portable privilege being introduced in the 10.8.1 release we also illustrated how a user assigned a role with this privilege can access manage and edit all versions within the service no matter their ownership or access level to the new release only service owners or portal administrators could complete such tasks we received a lot of requests of this capability as our old model restricted which users could complete quality assurance we are therefore very excited to provide this to everyone in the upcoming release prior to 2.6 and 10.8.1 french version web feature layers could only be taken offline if derived from the default version in this next release users have the option to create a version for each downloaded map which takes the data offline based on a newly created version this means the user can continuously sync to a named version which can then eventually go through the qa process and be posted to the default version branch versioning like traditional versioning now supports both object level conflict detection and column level conflict detection we saw this during our demo when reconciling our version where we were prompted with a dialogue acting as how we like to reconcile our version because we now support column level conflict detection branch version now supports field conflict filters field conflict filters are added to the underlying feature class and are used to ignore conflicts that occur between one or multiple designated fields finally geodatabase topology is finally moving to the web when your data is branch versioned you will be able to enable topology functionality when sharing your data as a feature service when you use these feature services in arcgis pro you will see your topology layers and you can work with them just like you would in a geodatabase i'm now going to pass it to john to start wrapping up the presentation we're almost at the end here so i wanted to quickly summarize some of the items we've discussed today number one branch versioning is a new versioning type that takes advantage of the services architecture and leverages the power of rest it's not a replacement for traditional versioning but it does offer new capabilities to work with version data in a services architecture evaluate your workflows to see if branch versioning is right for you due to its flat tree structure and architecture it offers simplified administration and a 24-hour system there's no need to compress no delta tables no pin states it's easy to prepare and publish your data just add global ids enable editor tracking and register as version through a branch versioning geodatabase connection to publish a map to your portal the default version is used for short transactions there's no undo redo whereas name versions allow a single editor or multiple viewers and finally conflicts are persisted across sessions providing the ability for administrators to review conflicts and reconcile and post these edits to the default i wanted to highlight some of the most frequently asked questions we've received from users at past conferences on geonet and through email hopefully these will address some of the questions you may have so justin one of the questions we often hear is can my geodatabase contain both traditional and branched version data yeah so that's a great question the same geodatabase can contain both traditional and branch version data traditional version data can be edited using a direct database connection while branch version data is edited through a feature service one thing to be careful about is which versioning type your geodatabase connection is configured for just like we saw in the demos today so here's one i hear a lot at conferences as a current user of traditional versioning i've used the traditional versioning workflows white paper to configure and communicate the recommended workflows within my organization is there a similar white paper i can reference for branch versioning we here at esri are still working to develop a white paper for branch versioning in the meantime though we have several blogs and web help topics that provide much of the same information in bite-sized chunks to help you get started with many changes and improvements being made this release so keep an eye out when the new documentation is available once 2.6 releases so justin what's the minimum version of arcgis enterprise and pro that i need to support branch versioning enterprise 10.6 within arcgis pro 2.1 is the minimum release supported with brand's versioning so here's a good one what happens to my data in versions when a service is deleted when a service is deleted the underlying data and versions actually continue to exist in the database if the service is deleted there are two ways to move forward if there are edits in your version which are no longer needed your first option would be for your geodatabase administrator to log into the geodatabase to delete the orphan versions if there are edits in your versions which you don't want to lose you can actually republish the data using the same content and service name doing this will link the versions and their associated edits to the feature service which can then be connected to and reconcile and posted if required so justin is it possible to publish multiple services off the same branched version data set yes so this is another great question you can publish multiple services from the same branch version data set as long as each service is uniquely named with that being said remember that in this scenario versions created in each service are independent of one another so here's a question in the same vein do all services published from a data source share the same default yes all services published for datastore share the same default version this default version exists in the underlying view database and is therefore referenced by each feature service referencing the same underlying view database this means that if the same data is published through several services edits made to the default version will be reflected in each service so here's one i received just a couple weeks ago for our last question our current qa processes are automated using traditional versioning right now is it possible to do the same thing with branch versioning of course we have documentation with the 2.6 release that provides helpful tips on how you can use automation with brand versioning you want to check out the automate reconcile and post operations topic once 2.6 is released thanks for that justin on behalf of justin annie and myself thank you for your time you

Channel: ArcGIS

Views: 3,411

Rating: 4.7777777 out of 5

Keywords: Esri, ArcGIS, GIS, Geographic Information System, ArcGIS Pro, geodatabase, data, data management, branch versioning

Id: vyBjuoVhoD8

Length: 38min 32sec (2312 seconds)

Published: Fri Aug 21 2020