File Lock

File Lock

Textil’s file lock feature prevents binary file editing conflicts before they happen. Cross-branch exclusive control and lineage tracking fundamentally prevent conflicts in team development.

Why File Lock Is Needed

Unreal Engine asset files (.uasset, .umap) are binary format. Unlike text files, Git’s automatic merge doesn’t work. When two people edit the same file, one person’s changes must be discarded.

File lock avoids this problem by “declaring before editing.”

Why Not Git LFS Locks?

Git LFS has a lock feature (git lfs lock), but it has fundamental issues with branch-based development.

Problems with traditional locks

1. 1
   Alice locks Hero.uasset on main
2. 2
   Alice edits, commits, and releases the lock
3. 3
   Bob tries to lock the same file on feature branch

   Lock is available, so he acquires it
4. 4
   Bob edits and commits
5. 5
   Merge feature into main

   Conflict occurs—one person's changes must be discarded

Even if a lock is available, the file may have been edited on another branch. Traditional locks only check “who currently holds it,” so they can’t prevent this problem.

Textil’s Approach: Lineage Tracking

Textil’s lock tracks file “lineage.” When acquiring a lock, it verifies whether the requester has the latest state. If not, the lock is denied.

How Textil's lock prevents conflicts

1. 1
   Alice locks Hero.uasset on main
2. 2
   Alice edits, commits, and releases the lock
3. 3
   Bob tries to lock on feature branch

   Denied: "You haven't incorporated Alice's changes"
4. 4
   Bob runs git merge main to incorporate Alice's changes
5. 5
   Bob tries to lock again

   Success

This verification guarantees that “if you can acquire the lock, you can safely edit.”

Global Scope

Textil’s locks are exclusive across branches. When you acquire a lock on one branch, the same file cannot be locked from other branches.

Since binary files cannot be merged, there’s no point in allowing independent locks per branch. Global scope fundamentally prevents merge conflicts.

Content-Based Identity

Lineage verification uses Git LFS oid (file content hash). This allows correct tracking even when commit history is rewritten by squash merge or rebase, as long as the file content is the same.

Tracking works even with squash merge

1. 1
   Edit Hero.uasset on feature branch (oid: abc123)
2. 2
   Squash merge to main (new commit, but oid is still abc123)
3. 3
   Another developer tries to lock

   oid matches, correctly determined as "has latest"

Real-time Sync

Lock state is shared with the entire team in real-time via WebSocket.

• When someone acquires a lock, everyone is notified immediately
• When someone updates a file (fetch/push), that information propagates to everyone
• Even if connection is lost, latest state is automatically restored on reconnection

This mechanism ensures everyone always sees the same lock state.

Target Files

The lock feature only applies to files managed by Git LFS. Text files (.cpp, .h, .ini, etc.) can be resolved through Git’s normal merge and are not lock targets.

In typical Unreal Engine projects, the following files are LFS-managed and lockable:

• .uasset - All asset files
• .umap - Level files
• Source files for textures, meshes, sounds, and other imported assets