Lore – Open source version control system designed for scalability
Epic Games has open-sourced Lore, a centralized version control system designed to handle massive game projects with large binary assets, aiming to fill gaps where Git and Git LFS struggle and to compete with Perforce. Commenters highlight features such as chunked storage, file locking, sparse checkouts, and tight engine integration as potentially transformative for game and media workflows, especially for artists. Enthusiasm is tempered by concerns over Lore’s production readiness, reliance on Epic, centralized architecture, and signs of LLM-generated documentation, as well as questions about whether it meaningfully improves on existing tools in practice.
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.