File locking has a reputation problem. In software development circles, pessimistic locking — requiring exclusive checkout before you can edit a file — is associated with old workflows, bottlenecks, and Perforce. Modern distributed version control is built around optimistic concurrency: everyone edits freely, conflicts get resolved at merge time.
That model works brilliantly for code. It falls apart for binary game assets.
The distinction is simple: optimistic concurrency assumes you can merge diverging versions. You can do that with text files. You cannot do that with a Photoshop document, a Maya binary file, an Unreal Blueprint, or a compiled audio bank. When two people edit the same binary asset and then try to merge, you do not get a conflict you can resolve — you get two versions and have to throw one away.
Pessimistic vs Optimistic: What the Terms Mean
Optimistic concurrency control assumes conflicts are rare and resolves them when they happen. In Git, you both work, then at merge time you resolve conflicts. The assumption is that most of the time, you are not editing the same lines.
Pessimistic concurrency control assumes conflicts are possible and prevents them from happening. You declare your intent to edit a file, the system grants you exclusive access, and everyone else is blocked from editing that file until you release the lock. Conflicts cannot happen because simultaneous editing is not allowed.
For text files, optimistic is usually better. For binary files with no merge path, pessimistic is the only viable option. The question is not which philosophy is correct — it is which one applies to the type of file you are working with.
Which Assets Need Locking
Hard requirement — no viable merge path
- Unreal Engine .uasset and .umap files
- Maya .mb and .ma binary files
- Photoshop .psd files
- Substance Painter .spp files
- Compiled audio banks (Fmod .bank, Wwise .bnk)
- Any proprietary DCC tool format
Usually needs locking — technically text, but merge is unreliable
- Unity .unity scene files (YAML, but structure makes manual merge error-prone)
- Unity .prefab files
- Unreal Engine .ini project settings files (conflicts here break the build)
Does not need locking — standard text merge works
- C++, C#, Python, Lua source files
- Plain .ini and .json configuration files
- Plain text documentation
Why Locking Alone Is Not Enough
A locking system that requires a command-line step will not be used by artists. Full stop. The workflow has to be integrated into the tool where the work happens.
In Perforce, the checkout-before-edit model is enforced at the file system level. Files are marked read-only by default. The editor cannot save a file without checking it out first. This means the locking happens automatically when work begins — users do not need to remember to do it.
In Git with LFS locks, the locking is advisory. Nothing stops someone from editing and pushing a file that someone else has locked. The server will reject the push, but the work has already been done. For non-technical team members who do not know to check lock status before starting, this is a source of wasted work.
Effective locking requires two things: server-side enforcement that prevents conflicting pushes, and editor-side integration that makes lock status visible and lock acquisition automatic when someone opens a file to edit.
Managing Locks at Scale
As your team grows, lock contention becomes a real concern. Artist A holds the lock on a character rig because she is still working on it. Artist B needs to make a quick change to the same rig for a demo that is due in two hours. What happens?
Without good tooling, this is a conversation that has to happen out-of-band — Slack message, ping on Discord, maybe someone physically walking to a desk. That works at small scale. At a studio with 30+ artists all working on a shared asset library, it does not.
You need a lock dashboard: a view that shows which files are currently locked, by whom, and ideally some indication of how long the lock has been held. You need a way to request a lock transfer — a notification to the current holder that someone else needs the file, with a clear path to transfer the lock when the current holder is ready.
Some studios set automatic lock expiry — if a lock has been held for more than 24 hours with no new commits, it releases automatically. This prevents abandoned locks from blocking work indefinitely. The right expiry period depends on your workflow, but having some expiry is better than none.
The Right Tool for the Job
File locking is not a workaround or a crutch. For non-mergeable binary assets, it is the correct technical solution. The engineers who designed optimistic concurrency control were not wrong — they just designed it for a different problem.
Game asset management has always required a different model than code management. The studios that accept this and invest in proper locking infrastructure spend less time recovering from conflicts and more time shipping content. The ones that fight it spend a disproportionate amount of time in asset recovery, conflict resolution, and "who has the latest version of this rig" conversations.
Locking is not the interesting problem. The interesting problem is making it invisible — integrated into the tools artists actually use, enforced automatically, and managed without requiring anyone to understand version control internals. That is the engineering challenge, and it is one worth solving properly.