Branched Versioning Explained: Multi-User Editing Without Data Conflicts

The Multi-User Editing Problem

Every GIS team with more than a handful of editors runs into the same problem: two people editing the same feature at the same time. Without version management, the last person to save wins, and the first person’s work is overwritten silently.

Traditional versioning (what Esri now calls “legacy versioning” in the SDE model) solved this decades ago. But it came with operational overhead that made many GIS administrators dread Monday mornings: state tree growth, compress cycles, orphan states, and reconcile/post workflows that could take hours on large geodatabases.

Branch versioning is the modern replacement. It handles multi-user editing through services rather than direct database connections, eliminates the state tree entirely, and integrates with web-based editing workflows that SDE versioning was never designed for.

How Branch Versioning Works

Branch versioning uses a fundamentally different architecture than SDE versioning. Understanding the mechanics helps you plan your migration and troubleshoot issues.

The Version Graph

Every branch-versioned feature service starts with a default version — the authoritative state of the data. Named versions branch off from default (or from other named versions), creating a directed graph of editing states.

Each named version:

Is a lightweight pointer, not a physical copy of the data
Tracks only the features that were actually edited in that version (deltas)
Can be created, edited, reconciled, and posted through REST API calls — no ArcGIS Pro required
Has a unique GUID and a human-readable name

The Edit-Reconcile-Post Workflow

Create a named version branched from default. Give it a descriptive name: “water-main-replacement-elm-street” or “parcel-subdivision-2024-0042”.
Edit in the named version. All changes are isolated — no other user sees them until you post. You can edit in ArcGIS Pro, a web app configured for versioned editing, or through the feature service REST API.
Reconcile your version against default. This pulls any changes other users have posted to default since you created your version. If conflicts exist (someone else edited the same feature you edited), you resolve them.
Post your reconciled changes to default. Your edits are now visible to everyone.
Delete the named version. Named versions are disposable — once posted, they have served their purpose.

Conflict Detection and Resolution

During reconcile, the system compares three states for every feature that was edited:

Common ancestor: The state of the feature when your version was created
Default: The current state in default (reflects other users’ posts)
Named version: Your edits

Conflicts occur when both default and your version modified the same feature (or the same attribute of the same feature, depending on your conflict detection setting).

Two conflict detection levels:

By object (row-level): Any edit to the same feature is a conflict, even if different attributes were changed. Safer but generates more conflicts.
By attribute (column-level): Only flags conflicts when both edits touched the same attribute. Fewer conflicts but requires more trust that editors are working on different aspects of the feature.

Branch Versioning vs. Traditional (SDE) Versioning

If your team is currently using SDE versioning, here is how the two compare:

State Tree and Compress Cycles

SDE versioning maintains a state tree in the geodatabase — every edit, reconcile, and post operation adds states. Without regular compress operations, the state tree grows unbounded, degrading query performance and bloating storage. GIS administrators often schedule weekly or daily compress cycles.

Branch versioning has no state tree. There is no compress operation because there is nothing to compress. The delta storage is managed internally and cleaned up when named versions are deleted.

Service-Based vs. Connection-Based

SDE versioning requires a direct database connection (SDE connection file in Pro) to create versions, edit, reconcile, and post. Web-based editing against SDE-versioned data is limited and has historically been fragile.

Branch versioning operates entirely through feature services. You create versions, switch versions, edit, reconcile, post, and delete versions through REST API endpoints. This means:

Web apps can participate fully in versioned workflows
Field Maps can edit versioned data (with some limitations on conflict resolution)
Python scripts can automate the entire version lifecycle via the ArcGIS API for Python or direct REST calls
No SDE connection files to manage or distribute

Performance Characteristics

Branch versioning queries are faster for reading the default version because there is no state tree to traverse. However, querying a named version involves reading the base data plus applying the delta, which can be slower for versions with many edits.

SDE versioning query performance degrades over time (between compress cycles) but is relatively consistent across versions.

Setting Up Branch Versioning

Prerequisites

ArcGIS Enterprise 10.6+ (for basic branch versioning) or 10.8.1+ (for full feature parity)
Enterprise geodatabase (SQL Server, PostgreSQL, or Oracle)
Feature class must not already be registered as SDE-versioned (you cannot run both simultaneously on the same feature class)
Feature class must be published as a feature service with versioning enabled

Step-by-Step Configuration

Register the feature class as branch-versioned. In ArcGIS Pro, right-click the feature class in the Catalog pane > Manage > Register as Branch Versioned. This adds the version management tables to the geodatabase.
Publish as a feature service. Share the map containing the branch-versioned feature class as a web layer to your Enterprise portal. Enable editing capabilities on the service.
Enable version management on the service. In the portal, navigate to the feature service item page > Settings > Version Management. Toggle on version management capability.
Create named versions via REST or Pro.
- In Pro: Version pane > New Version
- Via REST: POST {service_url}/VersionManagementServer/versions/create
- Via Python: VersionManager.create_version()
Configure the web map (if using web editing). Add the feature service to a web map. In the web map’s editing settings, enable version management to give web editors the ability to switch versions, reconcile, and post.

Version Management Automation

The REST-based nature of branch versioning makes automation straightforward. Common automated workflows:

Nightly Reconcile and Post

Schedule a Python script that:

Lists all named versions older than a threshold (e.g., 7 days)
Reconciles each against default
If no conflicts, auto-posts and deletes the version
If conflicts exist, sends a notification to the version owner

from arcgis.features import VersionManager

gis = GIS("https://portal.example.com/arcgis", "admin", "password")
service = gis.content.get("feature_service_item_id")
vm = VersionManager(service.url + "/VersionManagementServer", gis)

for version in vm.all:
    if version.properties.versionName == "sde.DEFAULT":
        continue
    result = vm.reconcile(version, "sde.DEFAULT", 
                         conflict_detection="byAttribute",
                         with_post=True)
    if result["hasConflicts"]:
        # Notify version owner
        pass
    else:
        vm.purge(version)

Version-Per-Work-Order Pattern

Integrate with your work management system to automatically create a named version for each work order, assign it to the responsible editor, and post/delete when the work order closes. This gives you a clean audit trail: every set of edits is tied to a specific work order.

Migration from SDE Versioning

Migrating an existing SDE-versioned geodatabase to branch versioning is a significant operation. The high-level process:

Reconcile and post all existing SDE versions. Only the default version migrates.
Compress the geodatabase to clean up the state tree.
Unregister from SDE versioning. This removes the add/delete tables and collapses all delta tables back into the base table.
Register as branch-versioned. This creates the new branch versioning infrastructure.
Republish feature services. Existing service URLs may change — update all consuming applications.
Retrain editors. The reconcile/post workflow is conceptually similar, but the UI and process differ. Plan for a training session and a 2-week parallel operation period.

Expect 4-8 hours of downtime for a moderately complex geodatabase (50-100 feature classes, 10-20 million features). Schedule migration during a planned maintenance window.

Limitations and Gotchas

No support for geometric networks. If your data uses geometric networks (legacy water/gas/electric), you must migrate to the Utility Network before adopting branch versioning.
No support for topology. Branch-versioned feature classes cannot participate in geodatabase topology. Use attribute rules for spatial validation instead.
Archiving changes. Branch versioning supports archiving (tracking historical feature states), but the archive tables are structured differently than SDE versioning archives. If you have workflows that query archive tables directly, they need updating.
Conflict resolution in web apps is limited. Pro provides a full conflict resolution dialog. Web map conflict resolution is available but less intuitive — complex conflicts may require Pro to resolve.

Frequently Asked Questions

Can branch versioning work with ArcGIS Online, or only Enterprise?

Branch versioning for hosted feature layers in ArcGIS Online was introduced at 10.8.1. However, the full version management capabilities (named versions, conflict resolution) are primarily designed for Enterprise deployments. AGOL supports a simplified versioning model for hosted feature layers that handles concurrent editing but does not expose the full version management API.

How many named versions can exist simultaneously?

There is no hard limit on the number of named versions. Practically, organizations run anywhere from 5 to 500 concurrent versions depending on team size and workflow. Performance impact is minimal because named versions only store deltas — the storage cost is proportional to the number of edited features, not the number of versions.

Can I branch from a branch, or only from default?

You can create named versions from any other version, not just default. This enables hierarchical workflows: a project manager creates a project version from default, and individual team members create their versions from the project version. The team reconciles and posts to the project version, and the project manager does a final reconcile and post to default.

What happens if I delete a named version without posting?

All edits in that version are discarded permanently. There is no recovery mechanism. The base data (default version) is unaffected. This is by design — named versions are intended to be temporary workspaces.

Is branch versioning compatible with replicas and distributed geodatabases?

Branch versioning works with one-way and two-way replicas in Enterprise. Check-out/check-in replicas are not supported with branch versioning. For disconnected editing scenarios (field crews without connectivity), consider offline-enabled feature services with sync capabilities instead of replica-based workflows.

Planning a migration to branch versioning? Book a discovery call with GeoLever — we help organizations modernize their geodatabase editing workflows without disrupting production.