Where Mercurial is native today
- Local commits without a network connection — also a TOVIO v1 design target
- Binary files versioned without an LFS store — also a TOVIO v1 design target
- Open formats + open-source engine — also a TOVIO v1 design target
Comparison · Mercurial
Mercurial is a distributed version control system of Git's generation, with its own command set and an extension model. Here is how it compares with Git and with TOVIO's design, row by row.
native / first-class partial or workaround not documented as native
Mercurial and Git cells reflect a 2026 snapshot, checked on , of each tool's publicly documented behavior. TOVIO cells reflect the v1 design target — TOVIO is pre-1.0, unpublished, and not yet independently audited. See the launch gates and what ships today and the sources and qualifications.
Read each complete row. Partial support includes limited coverage or extensions. An em dash means no native mechanism was documented in the reviewed sources, not that every external integration was ruled out. Local commits do not imply a fully distributed architecture. Direct binary storage does not establish asset-size limits, transfer efficiency, or performance.
| Capability | Mercurial | Git | TOVIO |
|---|---|---|---|
| Local commits without a network connection | Native or first-class | Native or first-class | Native or first-class |
| Per-file cryptographic permissions | No documented native support | No documented native support | Native or first-class |
| AI-agent capability tokens + provenance | No documented native support | No documented native support | Native or first-class |
| Change-centric identity (survives rewriting) | Partial or workaround | No documented native support | Native or first-class |
| First-class conflict objects | No documented native support | No documented native support | Native or first-class |
| Binary files versioned without an LFS store | Native or first-class | Native or first-class | Native or first-class |
| Path-scoped partial checkout | Partial or workaround | Native or first-class | Native or first-class |
| Operation log / local state restore | Partial or workaround | Partial or workaround | Native or first-class |
| Language-aware semantic diff | No documented native support | No documented native support | Native or first-class |
| AI configuration history with risk / rollback | No documented native support | No documented native support | Native or first-class |
| Open formats + open-source engine | Native or first-class | Native or first-class | Native or first-class |
Documentation checks, not independent execution tests of every product. Choose a tool for its scope and official references.
Sparse checkout is native. Git stores binary bytes without LFS, but large-asset storage and transfer have different tradeoffs from a dedicated asset workflow. Reflogs retain ref movements, not complete working-copy snapshots. Shallow and partial clones are exceptions to full-history cloning.
Changeset evolution tracks predecessor/successor relationships rather than an unchanged Change ID. Native history can store binary files directly. Sparse checkout and the optional largefiles workflow involve extensions; largefiles uses stand-ins and a separate central content store. History recovery is not a complete working-state operation log.
The column describes the v1 design target under supported profiles, not general availability. Undo depends on supported, retained operations. Semantic context is advisory; behavioral rollback records supplied AI configuration, not a running model. Signing-required repositories currently hold divergent lanes rather than automatically reconciling them. The Apache-2.0 core and commercial Forge have different licenses.