File Locking for Large Assets in Game Source Control

Game development relies heavily on large, non-textual binary assets such as 3D models, textures, audio files, and compiled shaders. Unlike source code, which can be merged line-by-line during a conflict, binary files are monolithic; if two developers modify the same binary asset simultaneously, their changes cannot be merged automatically, resulting in lost work. To solve this, version control systems employ file locking mechanisms that grant exclusive write access to a single user, preventing concurrent edits and preserving asset integrity.

Why Binary Files Require Exclusive Locking

When developers edit code, Git or other version control tools can easily merge changes from different branches because the files are plain text. However, binary formats are proprietary, compressed, or structured in ways that automated merge tools cannot parse. If Artist A and Artist B both edit the same 3D character model at the same time, the system cannot combine their changes. The only resolution is to overwrite one artist’s work with the other’s. File locking prevents this scenario by ensuring only one person has write access to a specific binary file at any given time.

How Perforce (Helix Core) Handles File Locking

Perforce Helix Core is the industry standard for major game development studios, largely due to its native, highly efficient handling of binary assets and file locking.

Perforce operates on a centralized architecture, which makes locking straightforward. It uses an “exclusive checkout” mechanism, often designated by the +l file type modifier. When a developer wants to edit a binary asset, they must “check out” the file from the central server. If the file is marked with the exclusive checkout attribute, Perforce locks the file on the server. Other developers are immediately blocked from checking out or editing that file until the original holder submits their changes or reverts the checkout.

How Git LFS (Large File Storage) Handles File Locking

Git is a distributed version control system, meaning every developer has a full copy of the repository. Historically, this made file locking nearly impossible. Git LFS (Large File Storage) was developed to handle large binary files by replacing them with text pointers in the main repository and storing the actual binaries on a separate server.

To prevent conflicts, Git LFS introduced a File Locking API. The workflow operates as follows:

  1. Locking: A developer runs the command git lfs lock <path/to/file>. The Git LFS server registers that this user has exclusive rights to the file.
  2. Local Enforcement: When other developers run git pull or git lfs checkout, Git LFS marks locked files as read-only on their local machines.
  3. Verification: Before pushing changes, Git LFS verifies that the pushing user holds the lock for any modified binary files. If they do not, the server rejects the push.
  4. Unlocking: Once the changes are pushed and merged, the developer releases the lock using git lfs unlock <path/to/file>.

How Subversion (SVN) Handles File Locking

Apache Subversion (SVN) is another centralized version control system widely used in smaller studios or legacy projects. Like Perforce, its centralized nature makes locking intuitive.

SVN uses the svn lock command. When a user locks a file, the central repository records the lock. Other users can still update their local working copies, but they cannot commit changes to the locked file. SVN also supports the svn:needs-lock property. When this property is set on a binary file, SVN automatically makes the file read-only on everyone’s local machine. The file only becomes writeable once a developer explicitly requests a lock from the server, preventing accidental local edits.

Integration with Game Engines

To make these locking systems seamless for artists and designers, game engines like Unreal Engine and Unity integrate directly with Perforce, Git LFS, and SVN APIs.

Inside the engine editor, when a developer attempts to modify a source asset (such as a level file or a blueprint), the engine automatically communicates with the source control server in the background. If the file is available, the engine checks it out and locks it automatically. If another developer already locks the asset, the engine displays a visual warning (such as a red icon) and prevents the user from making changes, ensuring smooth collaboration without leaving the creative environment.