Skip to main content
Documentation
Evaluation

Why evaluate Dits?

Dits is a focused experiment in open, local-first history for large media and asset pipelines—not a universal replacement for mature source, storage, or review systems.

The reason to try it

Try Dits if your project mixes Git-shaped history with large, frequently changing binary assets and you want to help test a model that can eventually connect exact source to edits, dependencies, and renditions. The present value is local history and storage experimentation; the differentiated long-term hypothesis is reproducible asset derivation.

The reason to wait

Wait if you need reliable multi-user synchronization, enterprise policy, broad format guarantees, supported plug-ins, service-level commitments, or proven performance at your scale. Established alternatives already provide many of those capabilities.

Choose for the job

OptionChoose it whenQuestion Dits must answer
GitThe repository is primarily code and text with modest binary assets.Does chunked large-asset history justify adding an immature tool?
Git LFSHosting compatibility and a familiar pointer workflow matter most.Does reuse within changing binary content matter for the workload?
XetOpen Git-compatible CDC, CAS, deduplication, and large-data workflows fit the job.Can explicit media structure and derivation add value above that substrate?
Perforce or Unity Version ControlThe team needs mature locks, administration, partial workspaces, and support now.Is an open local-first format valuable enough for an early pilot?
LucidLink, Frame.io, or a cloud driveFast access, review, approval, or simple sharing is the primary job.Does exact history and reproducible derivation solve a separate pain?

What Dits does not uniquely own

Content-defined chunking, a content-addressed store, chunk-level deduplication, Git integration, binary locks, streaming access, and review workflows all exist elsewhere. In particular, Xet already combines Git, CDC, CAS, and deduplication in an open Rust implementation.

Dits earns differentiation only if an explicit media and asset graph makes outputs easier to reproduce, changes easier to understand, and derived storage easier to manage. That claim still needs public workflow evidence.

A good alpha evaluation

  1. Choose disposable or independently backed-up representative data.
  2. Record the Dits version, filesystem, OS, file types, and commands.
  3. Commit controlled edits and inspect object-store growth.
  4. Check out every version and compare exact hashes.
  5. Interrupt operations and run integrity/recovery paths.
  6. Report favorable and unfavorable behavior with reproducible fixtures.