Arc

Checkpoint-based version control

A modern version control system built on full project snapshots, content-addressed storage, and pluggable backends.

How it works

• Snapshots, not diffs — every checkpoint captures the full project state as a manifest of content hashes.
• Content-addressed storage — files stored once by hash in a flat blob store. No tree objects, no pack files.
• Manifest-level delta compression — deltas track which files changed between snapshots, not binary byte ranges.
• Pluggable backends — same operations work against SQLite, PostgreSQL, or any storage backend.
• No staging area — checkpoint everything, or selectively include files with arc checkpoint -- file1 file2.

Get started

npm install -g arc-vcs
cd my-project
arc init
arc checkpoint "initial commit"

Documentation

Design

Arc stores each checkpoint as a complete manifest — a mapping of every file path to its content hash. There are no tree objects, no staging index, no pack file negotiation. The blob store is a flat key-value map from hash to content. Delta compression operates at the manifest level: Arc records which paths changed between two snapshots, not binary byte-level diffs within individual files.

What this enables

Because the storage interface is just key-value reads and writes, Arc works directly against any database — SQLite for local repositories, PostgreSQL or S3 for cloud-hosted ones. There is no filesystem assembly step. Checkpoints, branches, merges, and history traversal all operate directly on the storage backend. This makes Arc embeddable: import the functions and call them from your application code.

How it compares

Git uses tree objects, commit objects, and pack files with binary delta compression. Fossil stores artifacts in a single SQLite database with per-artifact zlib compression. Arc uses manifest-level deltas with content-addressed blobs and pluggable storage backends. Arc has no staging area — use selective checkpoint syntax instead.

Built by Alvei. MIT License.