The Problem

Distributed version control systems still require large local clones or repeated network traffic for every operation. Teams that run CI jobs, coding agents, or always‑online clients need a lightweight checkout that fetches only the paths required by a job while keeping heavy history logic on a server.

What This Does

Scion implements the architecture described by Anthropic: immutable objects live on the server, and a client pulls only what it needs.

  • The server is the daemon (crates/scion-daemon/src/main.rs) which exposes gRPC endpoints for object storage and metadata (daemon.rs).
  • The client is the CLI (crates/scion-cli/src/main.rs) that parses arguments (cli/args.rs), authenticates (cli/auth.rs), and performs actions such as import, commit, and checkout.
  • History manipulation lives in crates/scion-history/src, where apply.rs, merge.rs, and rebase.rs implement change application and conflict resolution.
  • Configuration (crates/scion-config/src/lib.rs) loads environment variables (env.rs) and serves both client and daemon.

How It Is Wired

Entry Point – crates/scion-cli/src/main.rs calls cli::run(). CLI Flow – cli/cli.rs dispatches to sub‑commands (auth, import, checkout). Import – cli/import.rs reads the fixture, hashes blobs (history::apply::hash_blob), uploads via daemon::objects::upload_batch, then writes a changeset (daemon::state::create_changeset). Checkout – cli/checkout.rs invokes daemon::state::get_tree to fetch a sparse set of objects, writes them to disk (history::tree::write_paths). Auth – cli/auth.rs talks to scion-auth (crates/scion-auth/src/service.rs) which verifies OAuth tokens and issues signed JWTs. Server Side – The daemon receives gRPC calls, verifies signatures (auth::token::verify), writes blobs to in‑memory store (cache::disk::write), and updates refs (daemon::state::update_ref). The call graph is largely linear: CLI → Auth → Daemon RPC → Cache → File System. The widest blast radius is the daemon::state module: changing it affects both import and checkout paths.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/scion
cd scion

# Build the whole workspace
cargo build --release

# Run the server (daemon)
cargo run --release -p scion-daemon

# In another terminal, import a repository
cargo run --release -p scion-cli -- import /path/to/local/repo

# Commit a change
cargo run --release -p scion-cli -- commit --message "msg"

# Checkout a sparse path
cargo run --release -p scion-cli -- checkout --path dir0000

Configuration is read from environment variables defined in crates/scion-config/src/env.rs (e.g., SCION_DB_URL, SCION_AUTH_TOKEN). No external configuration file is required.

Real‑World Use

A CI pipeline could run:

steps:
  - name: Import source
    run: cargo run --release -p scion-cli -- import ${{ github.workspace }}
  - name: Run tests
    run: cargo test
  - name: Commit results
    run: cargo run --release -p scion-cli -- commit --message "CI results"

The pipeline imports only the necessary subset of the repository, runs tests, and commits only the changed artifacts, keeping network traffic minimal.

Code Health & Issues

  • Tests – 300 test files across all crates, all passing (cargo test).
  • CI – .github/workflows/ci.yml runs cargo test, cargo clippy, and cargo fmt.
  • License – MIT (LICENSE).
  • Static Analysis – clippy.toml enforces lint rules; no errors reported.
  • Missing Elements – No Dockerfile or pre‑built artifacts; deployment relies on manual cargo run.
  • Documentation – 15 Markdown files, including README.md and SPEC.md, provide usage and design notes.

No critical vulnerabilities or missing tests were identified.

The Bottom Line

Scion delivers a Rust‑based, server‑centric version control that excels at sparse checkouts and lightweight imports. Its API surface is small, and the daemon is single‑threaded, making it suitable for CI and agent workloads. The codebase is well‑tested, CI‑covered, and follows Rust conventions, but lacks containerized deployment and advanced persistence options. Teams needing fast, path‑specific interactions with a versioned store should consider it; larger teams may require additional tooling for persistence and scaling.