Lore – Open source version control system designed for scalability

Original Article ↗ Hacker News Discussion ↗

Intended use and positioning

  • Seen mainly as a Perforce replacement for game development and other asset‑heavy workflows, not a general Git replacement.
  • Target users: teams mixing programmers and artists, with repos measured in hundreds of GB–TB and dominated by binary assets (textures, models, audio, levels).

Why Git (and Git LFS) struggle here

  • Git is excellent for text/code but poor for large binaries:
    • Repos and clones bloat quickly; history becomes huge and slow.
    • Git LFS adds locking and indirection but is described as fragile, confusing, and hard to configure at scale; frequent auth and corruption issues mentioned.
    • No fine‑grained permissions; access is repo‑wide unless you split repos or use awkward submodules.
    • Sparse checkout and partial clones exist but are sharp‑edged and not artist‑friendly.
  • Git’s CLI and output are widely criticized as confusing and overly verbose, especially for non‑engineers.

How Lore claims to help

  • Designed around large binary assets:
    • Chunked storage for deduplication and faster partial transfers.
    • On‑demand hydration / sparse working copies so users only pull assets they need.
    • Native file locking to prevent concurrent edits of non‑mergeable assets.
    • Per‑directory/asset permissions and multi‑tenant isolation.
  • Git‑like CLI for developers; a GUI desktop client for artists is promised (binary available now, source to be opened later).
  • Full API surface intended, unlike Git’s “no library” stance.

Centralization, scale, and architecture

  • Lore is explicitly centralized (more like Perforce than Git); peer‑to‑peer is a non‑goal.
  • Designed to back things like Unreal Engine/UEFN pipelines; described as already used internally for Fortnite content.
  • Multi‑region deployments currently depend on AWS services like DynamoDB, raising concerns about cloud coupling.

Tooling, UX, and adoption concerns

  • Many stress that UE and Perforce work well together today; migration inertia is high because artists dislike learning new tools.
  • Lore’s success seen as depending on deep integration with Unreal, Unity, DCC tools (Maya, Blender, etc.) and a polished GUI.
  • Some ask whether Lore is good enough at plain text/code to replace Git org‑wide; others note ecosystem lock‑in around Git tooling.

Trust in Epic and project maturity

  • Skepticism about tying core infrastructure to Epic:
    • Past decisions (e.g., dropped Linux/macOS support for games, Epic Store controversies) cited as trust issues.
    • Fear that Lore could be abandoned or turned into an “open core” upsell despite MIT licensing.
  • Docs and design pages are widely perceived as LLM‑generated, verbose, and hard to read; this undermines confidence in rigor even though the underlying system may be solid.
  • Some note it is not yet “production‑ready” per its own FAQ; many will wait for more real‑world reports.

Broader applicability and comparisons

  • Other domains (ML/AI datasets, CAD, 3D modeling, photography, PDM/PLM) see potential in a binary‑first VCS.
  • Compared to existing data/BLOB tools (git‑annex, DVC, lakeFS, Pachyderm, Oxen, XetHub) and other VCSs (Mercurial, SVN, PlasticSCM, Diversion, jj, Pijul); consensus is that “Git for data/gamedev” remains a hard unsolved problem, so more experimentation is welcome.