Comparison

TOVIO across the version-control landscape.

Individual properties below exist in some tool already. No system — not Git, not Perforce, not the new wave of rewrite-safe successors — combines them under one open, permissive specification. That gap is what TOVIO is built to close. Here is the honest map.

How to read this

A fair capability map, not a scorecard.

native / first-class partial or workaround not supported

Competitor cells reflect a 2026 snapshot of each tool's publicly documented behavior and will change as those projects evolve; where another system genuinely leads a row, the chart shows it. TOVIO cells reflect the v1 design target — TOVIO is pre-1.0, unpublished, and not yet independently audited. See thelaunch gates and what ships today for current implementation status.

On "per-file cryptographic permissions": TOVIO encrypts protected paths at snapshot and wraps their content keys only to authorized recipients, so a host or an unauthorized clone holds ciphertext it cannot read. That is cryptographically scoped, provenance-tracked, revocable access — not a claim that an authorized holder or the software can never see plaintext once it holds an entitled key.


The established landscape

Against the tools most teams run today.

Git, Subversion, Mercurial, and Perforce are the workhorses of shipped software. Perforce and Subversion still lead on native binaries and path-scoped checkout — TOVIO aims to match those while adding the guarantees none of them offer.

$established version control2026 snapshot · TOVIO = v1 design target
CapabilityGitSubversionMercurialPerforceTOVIO
Offline-first, fully distributedNative or first-classNot supportedNative or first-classNot supportedNative or first-class
Per-file cryptographic permissionsNot supportedNot supportedNot supportedPartial or workaroundNative or first-class
AI-agent capability tokens + provenanceNot supportedNot supportedNot supportedNot supportedNative or first-class
Change-centric identity (survives rewriting)Not supportedNot supportedPartial or workaroundNot supportedNative or first-class
First-class conflict objectsNot supportedNot supportedNot supportedNot supportedNative or first-class
Native large binaries (no add-on)Not supportedPartial or workaroundPartial or workaroundNative or first-classNative or first-class
Path-scoped partial checkoutPartial or workaroundNative or first-classPartial or workaroundNative or first-classNative or first-class
Full operation log / undo-anythingPartial or workaroundNot supportedPartial or workaroundNot supportedNative or first-class
Semantic diff & behavioral versioningNot supportedNot supportedNot supportedNot supportedNative or first-class
Open specification, no vendor lock-inNative or first-classNative or first-classNative or first-classNot supportedNative or first-class

The next-generation landscape

Against the systems reinventing the model.

A new wave — Jujutsu, GitButler, Diversion, Lore — is fixing real Git pain: rewrite-safe change identity, no staging area, first-class conflicts, native binaries. TOVIO shares those ideas and adds the cryptographic and agent-authorization layer they leave out.

$the next-generation landscape2026 snapshot · TOVIO = v1 design target
CapabilityGitJujutsuGitButlerDiversionLoreTOVIO
Offline-first, fully distributedNative or first-classNative or first-classNative or first-classNot supportedPartial or workaroundNative or first-class
Per-file cryptographic permissionsNot supportedNot supportedNot supportedPartial or workaroundNot supportedNative or first-class
AI-agent capability tokensNot supportedNot supportedPartial or workaroundPartial or workaroundNot supportedNative or first-class
Agent commit provenanceNot supportedNot supportedPartial or workaroundPartial or workaroundNot supportedNative or first-class
Change-centric identity (survives rebase)Not supportedNative or first-classNot supportedNot supportedNot supportedNative or first-class
First-class conflict objectsNot supportedNative or first-classPartial or workaroundNative or first-classNot supportedNative or first-class
No staging areaNot supportedNative or first-classNot supportedNative or first-classNot supportedNative or first-class
Binary parity (no LFS bolt-on)Not supportedNot supportedNot supportedNative or first-classNative or first-classNative or first-class
BLAKE3 content addressingNot supportedNot supportedNot supportedNot supportedNative or first-classNative or first-class
Lane pointers auto-reconcile when offline copies divergeNot supportedNot supportedNot supportedNot supportedNot supportedNative or first-class
Full operation log / undo-anythingPartial or workaroundNative or first-classNative or first-classPartial or workaroundPartial or workaroundNative or first-class
Semantic diffs & behavioral versioningNot supportedNot supportedNot supportedNot supportedNot supportedNative or first-class
Open specification, no vendor lock-inNative or first-classNative or first-classNative or first-classNot supportedNative or first-classNative or first-class

Next-generation rows mirror the capability matrix maintained in the project's README; a shared property with Jujutsu (change identity, no staging, conflict objects) is shown as shared, not claimed as unique.


A mechanism, not a headline

Why we're not a pure-CRDT VCS.

Two rows above — first-class conflict objects and lane pointers auto-reconcile — invite a fair question: if lane refs are CRDTs, is TOVIO just a CRDT that auto-merges everything? No. A pure sequence CRDT is the wrong substrate for source control, and TOVIO deliberately does not use one for its merge engine.

A pure sequence CRDT (an RGA or causal tree — the machinery behind live document co-editing) always produces a merged result: it deterministically interleaves two people's concurrent edits to the same lines. That is exactly right for a shared document, where you want everyone's keystrokes to survive. It is wrong for a VCS, where two incompatible edits to the same function must stop and ask a human — not be silently braided into code that neither person wrote.

So TOVIO's merge substrate is a conflict-representing interval graph (the Pijul / Darcs lineage), not a sequence CRDT. When concurrent edits overlap, it does not guess: it surfaces the overlap as a first-class conflict object the repository carries as data while everything else keeps working. Content itself lives on a content-addressed immutable DAG — nothing is ever interleaved away, and nothing is lost.

Mechanism note — where CRDTs actually live: the CRDT machinery — a last-writer-wins register ordered by a Hybrid Logical Clock — governs the pointer-propagation layer only: which commit a lane ref names as offline copies converge. It never touches your file content. The merge engine borrows just one idea from that world, a deterministic, replica-agnostic tie-break, but keys it on Change ID, never the wall clock, over that conflict-representing graph. So pointers converge without a lock and a merged tree hashes identically on every peer — while divergent offline tips reconcile on the lane into a merge-or-conflict commit (both tips its parents), never a stranded, off-lane orphan.

Design rationale: ADR-0025 (sound conflict-resolution algebra, §2 — a pure sequence CRDT is explicitly rejected for the merge engine) and ADR-0288 (on-lane divergence reconciliation at sync).


Measured, not asserted

How often does it actually conflict?

A finer merge substrate is only worth anything if it conflicts less on the work people really do. So we measured it: 2,800 concurrent edit pairs, the same bytes through Git's three-way merge and through TOVIO's. Git conflicted on 30.1% of them. TOVIO conflicted on 7.0% — about 4.3× fewer, a 77% reduction.

Where both developers editEdits eachGitTOVIO
Anywhere in the file11.3%0.3%
Anywhere in the file23.8%0.8%
Anywhere in the file310.8%2.8%
Same 20-line window112.8%2.0%
Same 20-line window239.0%7.0%
Same 20-line window366.8%13.0%
Same 8-line window276.5%23.3%
All 2,800 pairs—30.1%7.0%

Method. A 200-line file; both sides apply one to three random edits — modify, insert, delete — either anywhere in the file or confined to the same small window, which is what two people working in one function looks like. Both engines see byte-identical input. Measured 2026-09-11 against git merge-file (git 2.45.1); default and --zdiff3 agreed on every pair.

Why the gap. The two engines are built on different substrates and end up asking different questions of the same three files. That mechanism is worth seeing in full, so it has its own section below.

The number that keeps this honest: a merge engine can drive its conflict rate to zero by silently dropping an edit, so every clean merge above is audited, per trial, by the checker below. Where both engines merged cleanly the output was byte-identical — all 1,957 of those pairs; there was no pair Git merged and TOVIO refused; and on every clean merge, no inserted line went missing and no removed line came back.

That second result is what lets the same figure be stated over one population rather than two: because no pair exists that Git merged and TOVIO refused, TOVIO's conflicts are a subset of Git's. So of the 843 pairs Git stopped on, TOVIO settles 647 — 77% — with every line of both sides accounted for, and stops on the rest. The advantage narrows as the collision tightens: in the last row, both developers inside the same eight lines, it is 3.3× and TOVIO still conflicts on 23.3% of pairs. Two people rewriting the same line is a question for a human, and no version control system can merge it away.

Scope, stated plainly, because the figure above is the kind that gets quoted without it. The audit is textual. "Every line accounted for" means no line either side wrote went missing and no line either side removed came back. It does not mean the merged file still compiles: one side can delete a function while the other adds a call to it in a different file, and both merges are correct line by line.

TOVIO does catch that case — it is what the semantic layer is for. It flags an interface both sides changed incompatibly, and a symbol one side removed while the other newly referenced it, advisory by default and blocking on a lane that requires the check. What no one has measured is the rate: how often a clean merge breaks real code, and what share of those the detector sees. That needs a false-clean rate over real repository history, gated on a build and a test suite rather than on bytes. Until then, this figure belongs to the merge engine rather than to your codebase.

The rest of the boundary: this measures the content-merge decision on a synthetic corpus — not a study of real repositories, and not an end-to-end workflow claim. It excludes rename and binary conflicts, and it excludes the semantic layer, which by design reports more conflicts than Git does: a caller left behind by a changed signature is a conflict TOVIO surfaces and Git merges clean. Reproduce it in one command with scripts/verify_merge_conflict_rate.py, which regenerates the corpus, replays every pair through both engines and re-checks each figure and each audit claim above; crates/tovio-core/tests/merge_conflict_rate.rs holds the corpus generator and asserts TOVIO's half in CI, so this page cannot drift away from the engine.


The mechanism

What the two engines actually compare.

Both merges start from the same three files: the common ancestor, your version, and theirs. The difference is what each one builds out of them — and therefore what question it is able to ask when the two of you have edited the same file.

Git compares positions

Git diffs the ancestor against each side. What comes out is two lists of changed line ranges, and the merge walks them asking one question: do these two ranges overlap or touch? If they do, it has no way to tell the edits apart, so it brackets both as a conflict and asks you.

That is not a shortcut — it is the most a snapshot can support. Three blobs carry no record of who wrote a line, so position is the only handle the engine has. The practical consequence is a minimum spacing: two edits need at least one untouched line between them. Verified against git 2.45.1 — an edit on line 5 and an edit on line 6 conflict; move the second to line 7 and the same merge is clean.

TOVIO decides one line at a time

TOVIO decomposes each side against the ancestor too, but keeps two things a pair of diffs has no room for: which ancestor lines survived — matched by content, so the comparison is per line rather than per hunk — and the chg: Change ID that introduced each inserted run. The contest is then settled one ancestor line at a time: a line conflicts only when two sides changed that line differently. Edit different lines and you are never in contest, however close together you sit.

That decomposition is recomputed for every merge and never stored as a second source of truth. What makes it richer than a pair of diffs is not persistence but its inputs: the same three blobs plus the two Change IDs, which is exactly the identity a snapshot alone cannot supply.

When two people…GitTOVIOWhy
Two edits on adjacent linesconflictmergesDifferent ancestor lines, so neither contests the other.
Two inserts at the same pointconflictmergesBoth kept, ordered by the Change-ID tie-break.
Both append to the end of a listconflictmergesThe same case: two runs after one surviving line.
One deletes a line, the other edits the nextconflictmergesNeither touches the line the other did.
Both make the byte-identical editmergesmergesConverges to one copy — never duplicated.
Both rewrite the same lineconflictconflictBoth changed the same ancestor line.
One deletes a block another edited insideconflictconflictDelete versus modify; no safe answer.
Inserted runs that share a line but differconflictconflictConcatenating would duplicate the shared line.

Where two edits land in the same place. Two runs inserted after the same surviving line are not a coin flip. Identical ones collapse to a single copy, and distinct ones are ordered by a total rule made only of bytes — the inserting Change ID, then the content hash of the run's first line, then its length, then the run itself. No clock, no replica id, no server, so every machine computes the same file and it hashes identically everywhere. The exception is the last row of the table: runs that share a line without being identical conflict, because concatenating them would quietly duplicate that line.

A recorded resolution is anchored to content, not to line numbers. Once you do resolve a conflict, the region it belongs to is keyed by the hashes of the surviving lines bounding it. Edit something else in the file and the region still matches itself — which is why that answer keeps applying after a rebase, a re-sync, or on another lane, instead of being asked again every time the text shifts.

And the last three rows are the point. TOVIO refuses to auto-order whenever both sides changed the same content, one deleted what the other edited, or two inserted runs share a line without being identical — because concatenating them would silently duplicate it. Those are genuine contests, and the engine hands them to a person instead of guessing. A finer substrate is meant to stop asking about edits that were never in contest; it is not meant to answer the ones that are.

Edits on neighbouring lines

Alice computes the subtotal. Bob computes the tax. Consecutive lines, unrelated work.

Ancestor
function total(cart) {
let sum = 0;
let tax = 0;
return sum + tax;
}
Alice
function total(cart) {
let sum = subtotal(cart);
let tax = 0;
return sum + tax;
}
Bob
function total(cart) {
let sum = 0;
let tax = vat(cart);
return sum + tax;
}
Gitconflict
function total(cart) {
<<<<<<< yours
let sum = subtotal(cart);
let tax = 0;
=======
let sum = 0;
let tax = vat(cart);
>>>>>>> theirs
return sum + tax;
}
TOVIOmerged
function total(cart) {
let sum = subtotal(cart);
let tax = vat(cart);
return sum + tax;
}

Both append to the end of a list

The barrel file, the changelog, the route table. Two people add a line at the bottom.

Ancestor
export { alpha };
export { beta };
Alice
export { alpha };
export { beta };
export { gamma };
Bob
export { alpha };
export { beta };
export { delta };
Gitconflict
export { alpha };
export { beta };
<<<<<<< yours
export { gamma };
=======
export { delta };
>>>>>>> theirs
TOVIOmerged
export { alpha };
export { beta };
export { gamma };
export { delta };

Both rewrite the same line

Neither engine guesses. There is no correct answer to pick, and this is the floor the measured rate never goes below.

Ancestor
const TIMEOUT = 30;
const RETRIES = 3;
Alice
const TIMEOUT = 60;
const RETRIES = 3;
Bob
const TIMEOUT = 90;
const RETRIES = 3;
Gitconflict
<<<<<<< yours
const TIMEOUT = 60;
=======
const TIMEOUT = 90;
>>>>>>> theirs
const RETRIES = 3;
TOVIOconflict
conflict object
kindcontent
yoursconst TIMEOUT = 60;
theirsconst TIMEOUT = 90;
statusopen — nothing discarded

The land completed. Both sides are kept, the lane stays usable, and the question waits as data until someone answers it — once.

Every row of the table and every line of the three files above is captured output, not illustration: each was run through git merge-file (git 2.45.1) and through merge_content, the same entry point the measured corpus goes through. The only edit is to Git's conflict labels, which name temporary paths when it is driven as merge-file and are shown here as yours / theirs, the way a real merge writes them. Design rationale: ADR-0025 (sound conflict-resolution algebra) and ADR-0252 (commit-time line-op capture, which carries this identity across a chain of merges rather than re-deriving it each time).


Why the combination matters

The overlap is the product.

Read down the columns and the story is consistent: every rival leads somewhere, and no rival leads everywhere. TOVIO is the only column that combines these four axes at once — on an open spec, binary-equal, and offline-first.

Per-file cryptographic permissions

Access decided by encryption, not a server ACL. A host or unauthorized clone holds only ciphertext for protected paths.

Agent capability tokens + provenance

Every agent acts under a signed, expiring, path-scoped, revocable token, with model, task, and tool-manifest provenance on its work.

Change-centric identity + first-class conflicts

chg: ids survive amend, rebase, and cherry-pick; conflicts are typed, stored objects a repository can carry and still keep working.

Behavioral versioning of AI systems

Snapshot, diff, risk-assess, and roll back an AI system's behavioral surface — model, prompts, tools, guardrails — alongside the code.

Only TOVIO leads on per-file cryptographic permissions, agent capability tokens with provenance, behavioral versioning of AI systems, change-centric identity with first-class conflicts simultaneously. Individual pieces are available elsewhere; the combination under an open, permissive license is the gap this closes.


The honest footnote

What "design target" means here.

TOVIO's offline core, cryptographic permissions, agent control plane, distributed sync, the Git bridge, and the semantic layer are implemented under their documented supported profiles. The open phase is ecosystem, scale evidence, independent security audit, publication, and the Tier-2 enterprise train — so no TOVIO artifact is advertised as generally available yet. Theroadmap and launch gates track exactly what is built versus pending, and the documentation carries the full specification.


See the model, not just the matrix.

Open a real repository in the browser, walk the Git migration path, or price the hosted service.