Epic Games Version Control Lore Compared with Perforce / SVN / Git from a Practitioner's Perspective

Introduction

Epic Games released an open-source version control system called Lore in June 2026. It primarily targets projects where code and large binaries coexist, such as game and entertainment production. In this article, I install Lore locally and compare it with Perforce, SVN, Git, and Git LFS.

The real pain points in practice are not storage efficiency per se, but exclusive lock management, server round-trip dependency, licensing costs, and binary conflicts. In this article, I verified how Lore addresses these pain points through hands-on results. Lore has strengths in binary support, offline resilience, and deduplication. On the other hand, as of the time of writing (July 2026), it does not yet have mandatory locking to prevent work loss from simultaneous binary editing. This is where it differs from Perforce.

What is Lore

Lore is an open-source version control system released by Epic Games in June 2026. It primarily targets projects where code and large binaries coexist, especially game and entertainment production.

Test Environment

• OS: macOS 26.5.1 (Apple Silicon, arm64)
• Lore / loreserver: 0.8.4
• Git: 2.54.0
• Git LFS: 3.7.1
• Perforce (p4 / p4d): 2025.2 (macOS ARM64 native)
• SVN: 1.14.5

All tools were tested on the same machine, with the same data and the same operations. For storage comparisons, since differences in storage methods affect behavior, the file types and settings for each tool were standardized to typical production usage. Perforce used the default binary type (gzip-compressed full copy). The test data was synthetic binary generated with a fixed seed, with a base size of 200MiB. This data is nearly random and designed to be barely compressible.

Target Audience

• Those using Perforce who are troubled by per-seat licensing or server round-trip dependency
• Those involved in game development or entertainment production who handle a mix of code and large binaries
• Those handling large binaries with Git or Git LFS who are troubled by repository bloat or bandwidth costs
• Those who want to know how Lore actually behaves compared to Perforce, SVN, and Git

References

• Lore Official Repository (GitHub)
• Lore Official Documentation
• Lore System Design
• Lore FAQ
• Lore Roadmap

Test 1: Incremental Storage for a 1-byte Change

First, I measured how much storage increases on the repository side for each tool when a large binary is changed slightly.

After registering a 200MiB binary as the first version, I registered versions with the following three types of changes and measured the incremental storage increase.

1. Append to end: Append 4KiB to the end.
2. Insert near the beginning: Insert 4KiB near the beginning, shifting all subsequent byte offsets.
3. Change 1 byte in the middle: Rewrite only 1 byte in the center.

The measurement results are as follows. Values represent the storage increase when registering the modified version.

Git, Git LFS, and Perforce each added one full-size copy regardless of the size or type of the change. Even changing only 1 byte results in approximately 200MiB increase. This is because these tools do not compute diffs between versions of a binary. Git does not delta-compress binaries, Git LFS stores objects in their entirety, and Perforce binary type retains a full copy per revision.

SVN stores byte-level diffs using svndiff (which revision to use as the base is determined by a mechanism called skip-delta), so for appending to the end and changing 1 byte in the middle, the increase is only a few dozen KiB. However, for insertion near the beginning, it grows to about 8.1MiB. When an insertion shifts all subsequent bytes, byte-level diffing becomes less efficient.

Lore uses FastCDC, a content-defined chunking algorithm, keeping the increase to approximately 160 to 210KiB for all types of changes. Its strength against insertions is particularly notable. Even when an insertion shifts byte offsets, since chunk boundaries are determined by content, only the chunks affected by the change need to be added. In the insertion case, Lore was far below SVN.

This result has direct implications for storage costs and repository bloat. If you regularly update large assets with Git or Git LFS, a full-size copy accumulates in the history with every change. If assets are updated multiple times a week, the repository grows rapidly. This feeds into the storage and bandwidth costs of Git LFS.

Perforce is also a full copy, but Perforce is designed to withstand real-world use with features like partial sync assuming server operation. Lore's distinguishing feature is its attempt to combine the binary support of Perforce with delta efficiency exceeding SVN and Git, as an open-source solution.

Test 2: When Does Lore Send Content to the Server

During the measurements in Test 1, I noticed a particular behavior: the output of Lore's push. On the initial push containing a 200MiB file, the CLI displayed the following.

Pushing 1 fragment(s)
Pushed 1 fragment(s), 124.00 bytes

This reads as if only 124 bytes were sent. However, after the push, the server-side storage had increased to approximately 200MiB. The display and the reality were inconsistent.

After examining the source code and server logs, and verifying on actual hardware, the cause became clear. By default, Lore pre-uploads content to the server at commit time rather than at push time, when the server is reachable. The push only sends the branch pointer update and the remaining metadata.

The actual measurements were as follows. With the server running, I measured server storage after each operation for a 200MiB file.

With the default, storage jumps to approximately 200MiB immediately after commit, and barely increases during push. With --offline, no upload occurs at commit time, and everything is sent at push time.

This design has both benefits and caveats for real-world use.

As a benefit, push becomes faster when working online. Since content has already been sent at commit time, there is no large wait during the push just before a review or when publishing a branch. The transfer cost is spread out across individual commits. Note, however, that only the content (fragments) is sent to the server at commit time, and that content is not referenced from any branch until after the push. Therefore, it is premature to consider pre-commit uploads as a complete backup.

As a caveat, when the server is reachable, a default commit waits for the pre-upload to complete. Whereas a Git commit is entirely local and instantaneous, committing a large binary in Lore while online means the commit waits for the upload of the content itself. On slow connections or remote environments, commits can become heavy. If you want lightweight commits or want to explicitly work offline, use --offline as shown in Test 4.

For Git users, this may feel unintuitive. When online, a Lore commit effectively combines the commit with a content pre-upload, and only the branch publication is performed at push time.

Test 3: Exclusive Locking

This is the most important test for Perforce users. If two people simultaneously edit a binary that cannot be merged, one person's work is lost. Exclusive locking prevents this. For each tool, I set up two working copies (userA, userB) and verified whether userB could edit or update while userA held a lock.

Lore's Lock Only Notifies, It Does Not Block

Lore has lore lock acquire. Testing on actual hardware revealed the following behavior.

When userA acquires a lock, it is visible from userB's working copy as well. If userB tries to acquire a lock on the same file, the duplicate acquisition is rejected. Up to this point, the behavior looks similar to Perforce.

However, userB was able to edit the locked file, commit, and push. The overwrite succeeded without even a warning.

############ userB: editing and pushing a locked file
-- commit --
Commit succeeded
-- push --
Pushed revision 2 -> ... to branch main

Lore's lock is advisory. It shares who holds the lock and prevents double-locking, but it does not stop those without the lock from editing or pushing. This is consistent with the official FAQ. Mandatory locking is a future item on the roadmap.

Perforce's Exclusive Lock Blocks at the Point of Opening for Edit

In Perforce, using the file type +l (exclusive open) prevents userB from even opening the file for edit while userA has it open.

############ userB: p4 edit on the same file
//depot/model.bin - can't edit exclusive file already opened for edit
... //depot/model.bin - also opened by tester_a@wsA

userB could not open even one file. Since the server enforces this, simultaneous editing cannot occur in the first place.

SVN Also Blocks at the Commit Stage

In SVN, files with svn:needs-lock set become read-only in the working copy, signaling that a lock should be obtained. This read-only state is an advisory mechanism, just like Git LFS, and can be removed with chmod +w. However, SVN differs from Git LFS in what happens next. After userA acquires a lock, userB's attempt to acquire a lock is rejected, and even if userB removes the read-only flag, edits the file, and tries to commit, the server rejects it. Whereas Git LFS's push blocking depends on client configuration (locksverify), SVN rejects commits from non-lock-holders at the server level.

svn: E160039: User 'userB' does not own lock on path '/model.bin' (currently locked by 'userA')

Git LFS Enforcement Depends on Client Configuration

Git LFS has git lfs lock. Testing against lfs-test-server revealed three stages of behavior. First, when --lockable is set, files become read-only in working copies of non-lock-holders. Second, double-locking is rejected. Third, whether push is blocked depends on the client-side locksverify setting. If locksverify is set to true, pushes from non-lock-holders are blocked. Without this setting, a warning is issued but the push goes through.

However, the read-only flag can be removed with chmod +w, and setting locksverify to false disables the verification. Unlike Perforce, where the server always enforces the rule, enforcement depends on client configuration and operational practice.

Lock Enforcement Strength of All Five Tools

The ranking of enforcement strength revealed by testing is as follows.

Perforce and SVN enforce at the server level. Git LFS suppresses conflicts through read-only enforcement with --lockable and double-lock rejection, and with locksverify=true can block pushes as well, but this enforcement depends on client configuration and can be bypassed with chmod +w or locksverify=false. Lore currently prevents double-locking but is purely advisory in that it does not stop editing or pushing.

Game development teams using Perforce structurally prevent simultaneous editing of binaries through exclusive locking to avoid work loss. Lore's current locking does not provide this protection. Even if you hold a lock, others can overwrite your work.

Test 4: Can You Work Offline

One of the pain points with Perforce is server round-trip dependency. If you cannot connect to the server, your work stops. I verified how Lore addresses this.

In Lore, even with the server stopped, I was able to commit and create branches by adding --offline. After restarting the server, synchronization via push was successful.

############ While server is stopped
lore --offline commit "v2 offline edit"   -> Commit succeeded
lore --offline branch create feature-offline -> Created branch
############ After server restart
lore push -> Created feature-offline, sent fragments

In contrast, Perforce in centralized mode could not even open files for editing when the server was stopped.

############ While server is stopped
p4 edit note.txt -> TCP connect to localhost:1668 failed. connect: Connection refused

As distributed and remote development becomes the norm, offline resilience directly affects team productivity. On teams using Perforce in centralized mode, work stops completely when the VPN is unstable, during server maintenance, or while traveling. Lore maintains the convenience of centralized operation while removing this constraint with --offline. You can continue committing and creating branches while on the move, then sync with a push when connectivity returns.

However, as seen in Test 2, Lore's default commit pre-uploads to the server when it is reachable. When you want lightweight offline work, explicitly use --offline.

Test 5: What Happens When Binaries Conflict

I verified what happens when two branches each modify the same binary separately and are then merged. In Lore, during the merge, a 3-way diff was computed, and a binary conflict was detected.

Merged files, 0 updated, 0 deleted, 0 merged, 1 conflicted
Files in conflict:
model.bin

Resolution is done with lore branch merge resolve mine or theirs, meaning you choose one side entirely. When I actually chose theirs, the content became the version from the source branch.

The fact that binaries cannot be merged carries heavy implications for the daily reality of game development. When two people separately edit the same asset and it conflicts, no tool can do anything other than discard one version entirely. In other words, one person's work is lost. This is precisely why exclusive locking to prevent conflicts before they happen is critically important. This is where the results of Test 3 become meaningful. Lore's lock is currently advisory and cannot stop non-lock-holders from overwriting. This means that in Lore, even if you hold a lock, a binary conflict can still occur, that conflict can only be resolved by choosing one side, and someone's work can be lost. Perforce's mandatory locking is the mechanism designed to solve this problem.

Summary

Here is a summary of the results from hands-on comparison of Lore with Perforce, SVN, Git, and Git LFS.

Lore's strengths were clear. It efficiently stores small changes to binaries as deltas using FastCDC, with particular strength against insertions. Despite being centralized, it supports offline work with --offline. When online, content is pre-uploaded at commit time, making push faster. And it is open-source with no licensing costs.

On the other hand, the most notable concern at this point is that mandatory locking is not yet implemented. Lore's locking is advisory and cannot prevent work loss from simultaneous binary editing. Since no tool can merge binaries, the presence or absence of this protection makes a significant difference in real game development environments. Teams that rely on Perforce's exclusive locking will need to evaluate this against their own workflows.

Mandatory locking is on Lore's roadmap and is a gap that may be filled in the future. The direction of combining binary support and offline resilience while remaining open-source is a noteworthy option for teams that have been caught between Git and Perforce.