Epic Games Version Control Lore Compared with Perforce / SVN / Git from a Practical Standpoint
This page has been translated by machine translation. View original
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. This article walks through installing Lore locally and compares it with Perforce, SVN, Git, and Git LFS.
The real pain points in the field are not storage efficiency per se, but rather exclusive lock management, server round-trip dependency, licensing costs, and binary conflicts. This article verifies how Lore addresses these pain points through hands-on results. Lore's strengths lie in binary support, offline resilience, and deduplication. On the other hand, as of now (July 2026), it lacks mandatory locking to prevent work loss from simultaneous binary editing. This is the key difference 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, each tool's file type and settings were aligned to standard configurations reflecting real-world usage. Perforce used the default binary type (gzip-compressed full copy). The test data consisted of synthetic binaries 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 mixed code and large binary files
- 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 Growth from a 1-Byte Change
First, I measured how much repository storage grows for each tool when a large binary is changed only slightly.
After registering a 200MiB binary as the initial version, I registered versions with the following three types of changes and measured the incremental storage.
- Append to end: Append 4KiB to the end.
- Insert near the beginning: Insert 4KiB near the start, shifting all subsequent byte offsets.
- Single byte change in the middle: Rewrite just one byte in the center.
The measurement results are as follows. Values represent the storage increment when registering the modified version.
| Change Type | Git | Git LFS | SVN | Lore | Perforce |
|---|---|---|---|---|---|
| Append 4KiB to end | ~200MiB | ~200MiB | ~43KiB | ~191KiB | ~200MiB |
| Insert 4KiB near beginning | ~200MiB | ~200MiB | ~8.1MiB | ~207KiB | ~200MiB |
| Single byte change in middle | ~200MiB | ~200MiB | ~39KiB | ~163KiB | ~200MiB |
Git, Git LFS, and Perforce added a full copy every time, regardless of the size or type of change. Even changing just one byte results in approximately 200MiB of growth. This is because these tools do not compute deltas between binary versions. Git does not delta-compress binaries, Git LFS stores objects whole, and Perforce's binary type keeps a full copy per revision.
SVN stores byte-level diffs using svndiff (which revision serves as the base is determined by a mechanism called skip-delta), so appending to the end and changing a single byte in the middle stayed within tens of KiB. However, inserting near the beginning grew to about 8.1MiB. When an insertion shifts all subsequent bytes, byte-level diffing becomes less efficient.
Lore uses content-defined chunking called FastCDC, keeping the increment between roughly 160 to 210KiB for all change types. Its resilience to insertions is particularly notable. Even when an insertion shifts offsets, boundaries are determined by content, so only the affected chunks need to be added. In this insertion case, Lore was significantly lower than SVN.
These results directly relate to storage costs and repository bloat. When large assets are updated regularly with Git or Git LFS, full-size copies accumulate in history with every change. If assets are updated multiple times a week, the repository balloons quickly. This is what drives the storage and bandwidth costs of Git LFS.
Perforce also uses full copies, but Perforce is designed for server-based operation and is built to handle real-world use through features like partial sync. Lore's distinguishing characteristic is its attempt to combine binary support comparable to Perforce with delta efficiency exceeding SVN and Git, all as open-source software.
Test 2: When Does Lore Send Content to the Server
During the Test 1 measurements, I noticed a particular behavior in Lore's push output. 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, server-side storage had grown by approximately 200MiB. The display and reality did not match.
After examining the source code and server logs and running hands-on verification, the cause became clear. By default, when the server is reachable, Lore pre-uploads content to the server at commit time rather than during push. The push only sends branch pointer updates and remaining metadata.
The hands-on measurements were as follows. With the server running, I measured server storage after each operation for a 200MiB file.
| Operation | Default commit | Commit with --offline |
|---|---|---|
| After stage | ~930 bytes | ~931 bytes |
| After commit | ~200MiB | ~931 bytes |
| After push | +~340 bytes | ~200MiB |
By default, storage spikes to approximately 200MiB immediately after commit, with almost no growth during push. With --offline, no upload occurs at commit, and everything is sent during push.
This design has both benefits and caveats for real-world use.
On the positive side, push becomes faster when working online. Since content is already sent at commit time, there is no large wait during push right before a review or branch publication. Transfer costs are distributed across individual commits. Note, however, that only the content (fragments) is sent to the server at commit time; that content is not referenced by any branch until after push. Therefore, it would be premature to treat pre-push commits as a complete backup.
As a caveat, when the server is reachable, a default commit waits for the pre-upload to complete. While a Git commit is entirely local and nearly instant, committing large binaries in Lore while online means the commit waits for the upload of the content itself. On slow connections or in remote environments, commits can become heavy. When you want lightweight commits or explicitly want to work offline, use --offline as shown in Test 4.
For Git users, this may feel unfamiliar. An online Lore commit effectively combines a commit and a content pre-upload, with only the branch publication happening at push.
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. I set up two working copies (userA, userB) for each tool and verified whether userB could edit or update while userA held a lock.
Lore's Lock Notifies but Does Not Block
Lore has lore lock acquire. Hands-on testing revealed the following behavior.
When userA acquires a lock, that lock is visible from userB's working copy. If userB tries to acquire a lock on the same file, the duplicate acquisition is rejected. Up to this point, it looks similar to Perforce.
However, userB was able to edit, commit, and push the file that userA had locked. The overwrite succeeded without even a warning.
############ userB: Edit and push a locked file
-- commit --
Commit succeeded
-- push --
Pushed revision 2 -> ... to branch main
Lore's locks are advisory. They share who holds a lock and prevent double-locking, but they do not stop non-lock-holders from editing or pushing. This is consistent with what the official FAQ states. Mandatory locking is a future item on the roadmap.
Perforce's Exclusive Lock Blocks at the Point of Editing
In Perforce, using file type +l (exclusive open) means that while userA has the file open for editing, userB cannot even open it for editing.
############ userB: p4 edit 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 a single file. Because the server enforces this, simultaneous editing is structurally impossible.
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 must be obtained. This read-only state is an advisory mechanism, like Git LFS, that can be bypassed 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 when userB bypasses the read-only flag, edits the file, and attempts to commit, the server rejects it. While 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 levels of behavior. First, setting --lockable makes files read-only in working copies for non-lock-holders. Second, duplicate lock acquisition is rejected. Third, whether push is blocked depends on the client-side locksverify setting. With locksverify set to true, pushes from non-lock-holders are blocked. Without the setting, there is only a warning and the push goes through.
However, the read-only flag can be bypassed with chmod +w, and setting locksverify to false disables the check. Unlike Perforce, where the server always enforces, enforcement depends on client configuration and operational practices.
Lock Enforcement Strength of the Five Tools
The enforcement ranking revealed by testing is as follows:
Perforce and SVN enforce at the server level. Git LFS deters through read-only enforcement via --lockable and duplicate lock rejection, and with locksverify=true can also block pushes, but that enforcement depends on client configuration and can be bypassed with chmod +w or locksverify=false. Lore currently prevents double-locking, but does not stop editing or pushing by non-lock-holders — it is purely advisory.
Game development teams using Perforce structurally prevent simultaneous binary editing through exclusive locks, avoiding work loss. Lore's current locks do 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 its server round-trip dependency. If you cannot connect to the server, work stops. I verified how Lore addresses this.
In Lore, even with the server stopped, I was able to commit and create branches using the --offline flag. After restarting the server, I was able to sync via push.
############ Server 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.
############ Server stopped
p4 edit note.txt -> TCP connect to localhost:1668 failed. connect: Connection refused
As distributed and remote development becomes more common, offline resilience directly affects team productivity. In teams using centralized Perforce, work stops completely when the VPN is unstable, during server maintenance, or while traveling. Lore maintains the usability of centralized version control while lifting this constraint with --offline. You can continue committing and creating branches while traveling and sync via push once connectivity is restored.
Note, however, that as seen in Test 2, Lore's default commit pre-uploads to the server when it is reachable. Use --offline explicitly when you want lightweight offline work.
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, the merge computed a 3-way diff and detected a binary conflict.
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 — that is, selecting one side entirely. When I actually chose theirs, the content became the version from the merge source branch.
The fact that binaries cannot be merged carries significant weight in the daily reality of game development. When two people edit the same asset separately and a conflict occurs, there is no choice but to discard one version entirely, regardless of which tool is used. In other words, one person's work is lost. This is precisely why exclusive locking that prevents conflicts before they happen is critically important. This is where the results of Test 3 become meaningful. Lore's locks are currently advisory and cannot stop non-lock-holders from overwriting. This means that in Lore, binary conflicts can still occur even when you hold a lock, those conflicts can only be resolved by picking 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 hands-on comparison of Lore against Perforce, SVN, Git, and Git LFS.
Lore's strengths were clear. It efficiently stores deltas for small binary changes using FastCDC, with particular resilience to insertions. It supports offline work via --offline while remaining centralized. When online, content is pre-uploaded at commit time, making pushes faster. And it is open-source with no licensing costs.
The most notable concern at this point, however, is that mandatory locking is not yet implemented. Lore's locks are advisory and cannot prevent work loss from simultaneous binary editing. Since binaries cannot be merged by any tool, the presence or absence of this protection makes a significant difference in game development environments. Teams relying on Perforce's exclusive locking need to evaluate Lore 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 with offline resilience while being open-source is a noteworthy option for teams that have been torn between Git and Perforce.