Evaluate TOVIO against your current system¶
TOVIO is a new version-control format and engine, not a hosting skin over Git. A useful comparison therefore starts with the requirements you need to verify rather than a point-in-time scorecard about other products. Competitor features, licenses, prices, and availability change independently; consult each product's current primary documentation before making a purchasing or migration decision.
Implementation is not general availability
Phases 0–4 are implementation-complete under their documented supported profiles. Phase 5 release publication, hosted-service and Enterprise completion, packaging, and external evidence remain open, so this page is an architecture evaluation aid—not an availability or performance claim.
Requirement matrix¶
| Requirement | TOVIO implementation | Boundary to verify |
|---|---|---|
| Stable work identity | A Change ID remains distinct from commit addresses as history is rewritten. | Import/bridge mappings and the workflow expected by existing automation. |
| Protected paths | Non-ANY read policy encrypts the protected payload at snapshot time and wraps its data key for authorized recipients. |
Public content, names, paths, policy metadata, recovery roles, and explicitly disclosed plaintext remain separate boundaries. |
| Agent authorization | Signed capability chains bind repository, paths, operations, lifetime, delegation, clearance, and provenance context. | A capability does not sandbox arbitrary local tools or a model endpoint that an authorized user feeds plaintext. |
| Conflicts | Typed, addressed conflict objects preserve both sides and their resolution representation. | A CRDT lane pointer can converge while incompatible content still requires explicit resolution. |
| Binary objects | FastCDC chunks and verified addressed storage use the normal object/sync path rather than a separate LFS protocol. | Measure workload-specific storage, latency, and checkout behavior on accepted release artifacts; no public benchmark is claimed yet. |
| Offline work | The local core can commit, inspect, switch, land, resolve, and undo supported retained operations with materialized objects and keys. | Sparse, partial, shallow, and lazy profiles may need an authenticated promisor to hydrate missing objects. |
| Synchronization | Native TLS and HTTP-framed exchange support full and filtered profiles; HLC/CRDT lane updates converge deterministically. | Authorization, protected refs, locks, quotas, closure verification, and transport failures may refuse an exchange. |
| Forge collaboration | The Forge --- a commercial product --- provides proposals, review, locks, audit, events, administration, backup, and synchronization. | It remains trusted for hosted operations, integrity, availability, visible metadata, and authorized disclosure edges. |
| Format portability | Storage, wire, policy/token, and conformance contracts are versioned in the Apache-2.0 specification. | Public V1 release artifacts and independent conformance evidence remain launch gates. |
| Commercial service | The accepted catalog and provider-neutral commerce controls are versioned in the repository. | TOVIO Cloud, generally available Enterprise Tier-2 artifacts, checkout, SLA, and support remain unavailable until their evidence and legal gates pass. The private CP-ABE KA implementation is not a service-availability claim. |
Conventional Git workflow mapping¶
This narrower comparison is stable enough to use during migration planning:
| Conventional Git concept | TOVIO concept |
|---|---|
| Commit hash used as work identity | Stable Change ID plus addressed commit snapshots |
| Branch ref | Lane CRDT register |
| Staging index | Current change records selected working-copy edits directly |
| Merge/index conflict state | Typed conflict object |
| Repository/host ACL | Write/admin gates plus cryptographic policy for protected reads |
| Personal or CI credential | Human identity or bounded agent-session capability chain |
| Pull request | Proposal attached to a Change ID and reviewed commit |
| Git LFS side protocol | Chunked binary objects in the normal TOVIO object model |
See Coming from Git, migrate from Git, and branching models for the operational details.
Questions for any evaluation¶
Run the same checklist against TOVIO and every alternative:
- Which bytes are encrypted, and which metadata, endpoints, administrators, recovery roles, and model or runner disclosures remain trusted?
- Can authorization be exercised offline, and what happens when keys, policy, or object closure is missing?
- Are agent credentials repository-, path-, operation-, lifetime-, and delegation-bound? Can ancestor revocation be demonstrated?
- Does conflict state survive as inspectable data, and does pointer convergence preserve both addressed histories without silently landing either one?
- Are large binaries part of the primary verified storage protocol or a separately operated service?
- Which full, sparse, partial, shallow, and lazy profiles are supported, and what credentials can each use?
- Are backup, restore, upgrade, downgrade, failure, cross-tenant, and load claims backed by current artifacts and independently reviewable evidence?
- What is open source, source-available, or commercial, and may the server legally be offered as a managed service?
For TOVIO, the current answers live in the roadmap, security model, Forge trust boundary, and licensing reference.
Last reviewed September 9, 2026
Suggest an improvement to this page Not for security reports — see disclosure