First Look at Epic Games Lore VCS

Programming, graphics, games, media, C++, Windows, Internet and more...

Sorry, you need Javascript on to email me.

-->

Main PageBlogProductionsAbout

Blog "

First Look at Epic Games Lore VCS

Thu

18

Jun 2026

June 17th, 2026, Epic Games announced Lore - a new version control system for software developers, to compete with Git and Perforce. Being old enough to have worked with the old CVS and SVN, and having experience working with Git and Perforce, I am quite interested in what changes this new system brings.

In my article Thoughts Beyond C++ from December 2024, I described my opinion about the problems I can see with current version control systems and the improvements a better one could bring, especially for game development. Let's see whether Lore advances any of these topics.

Key pages about Lore:

https://lore.org/ - home page

https://github.com/EpicGames/lore - GitHub repository

Quickstart: Your first Lore repository - quick start tutorial

Lore CLI command reference - description of all commands

The Lore Version Control System - lengthy design doc

I didn't test the app myself so far, but I've read some of the docs to get an idea of what it is and how it compares to Git and Perforce. tl;dr: It looks promising, although not revolutionary. Here is a summary and my thoughts.

General

The fact that it's made by Epic, the company behind Unreal Engine and Fortnite, is already a big plus, because it increases the chances of it being well supported and maintained. Despite being a pre-release version 0.x as a standalone product, it's already battle-tested, because when it was formerly called Unreal Revision Control, it was the built-in version control system for UEFN, where creators have been using it to version their Fortnite islands. Which means its lineage is already used in UEFN, but the standalone open-source product should still be treated as early.

Another advantage is that it's open source, under an MIT license, which also means it's free to use for personal as well as commercial purposes. Git is also open source, but other VCSs like Perforce/P4/Helix Core, Plastic, or Ark are not. Only the desktop client is available as a binary download and is not open source yet because it depends on proprietary components, but Epic is committed to open-sourcing it later.

The fact that it's written in Rust is also a good sign, increasing the chances of good performance (because Rust is a native language, unlike Java, C#, or JavaScript), as well as security and stability (because strong memory safety in Rust helps avoid many bugs that are notorious in C and C++). Offering APIs for C/C++, C#, Rust, Go, Python, and JavaScript is also great, because it can facilitate the development of tools that can integrate with this system - whether alternative GUI clients just for Lore, or support for it added to various text/code/asset editors.

Of course, a VCS like this encompasses many design decisions and many technical details behind the actual implementation or the shape of the API, CLI, or GUI. I will avoid low-level details here (like the use of Merkle trees) and instead focus on what's visible to the user.

Handling large files

The main promise of Lore is better handling of large binary files compared to Git (including Git with LFS). Epic claims that binary files rather than text files are natural to their system, with no conversions like line endings happening in the background, and any text-based processing implemented on top of the core system. Data stored in a repository is deduplicated not only at the level of an entire file, but also per fragment, which saves space even when only a part of a large binary file changes between revisions. Their documentation states that thanks to clever algorithms using data hashing, it works even when some data is inserted in the middle of a file! This is great news for game developers and other developers working with large binary assets.

Moreover, Epic claims that Lore is scalable in multiple "axes", allowing it to work efficiently with many repositories, many branches per repository, many files, large binary files, etc. If this is true, it makes the system a good fit for extensive software projects, like video games.

Lore seems to follow Git's approach of downloading the data from the remote repository first to a hidden directory .lore (similarly to .git), and then copying it to the working directory files. It means that, unlike Perforce, it may require disk space of at least 2x the working copy size, similarly to Git with LFS (subject to compression and deduplication). Lore claims to use sparse/lazy fetching as the default mode, but I suspect this just means that only the selected revision of all the files is downloaded rather than all their historical versions.

The advantage of this approach is, of course, the ability to inspect commit history, switch branches, diff, commit, etc. fully offline (unless it needs fragments that...