When Your Assets Can't Merge: Subversion's Lock-Modify-Unlock Model for Binary Files

Two artists edit the same level_03.blend file on the same day. Whoever commits second gets a conflict that no merge tool on earth can resolve, because binary files don't diff. One person's afternoon of work gets overwritten, and the version control system that was supposed to prevent exactly this just shrugs.

This is the scenario where Apache Subversion's file locking earns its keep. The thesis is simple: copy-modify-merge is the right default for text, but for unmergeable assets you want lock-modify-unlock, and Subversion has this built in as a first-class feature, not a plugin.

Why merging fails for binaries

Subversion's default workflow assumes concurrent edits can be reconciled. For source code, two people can edit the same file and the system merges their changes. For a Photoshop file, a CAD model, or an Excel workbook, there is no meaningful merge. The only safe strategy is serialization: one person at a time. You could enforce this by policy — a wiki page saying \"please don't touch the rigging files while someone else is working.\" Or you could make the tooling enforce it. Subversion's answer is the svn:needs-lock property plus the svn lock command.

How svn:needs-lock flips the workflow

Setting svn:needs-lock on a file does two things. First, Subversion makes the working copy read-only. The file literally cannot be edited until you obtain the lock. Second, the repository tracks a server-side lock token tied to your working copy. The read-only bit is the key insight: the discipline is self-enforcing. You don't have to train people to remember to lock — they physically can't modify the file without running svn lock first. The lock is visible to everyone: running svn info against the file's repository URL shows the lock owner and creation date without needing a working copy at all, so a teammate can check who holds a file before starting duplicate work on an expensive asset.

A worked example

Assume a repository at https://svn.example.com/game-assets with a file models/hero.psd. From a working copy, an administrator or senior artist with commit rights runs:

# In the working copy, as a user with commit access\nsvn propset svn:needs-lock '*' models/hero.psd\nsvn commit -m \"Require lock for binary art\"\n\n# Later, before editing\nsvn lock models/hero.psd\n# ... edit the file ...\nsvn commit -m \"Update hero texture\" models/hero.psd\n

After the property is committed, the working copy file becomes read-only. Attempting svn lock from a second working copy fails with an error naming the lock owner. To check the lock without a checkout: svn info https://svn.example.com/game-assets/models/hero.psd shows the lock owner and token. If a lock goes stale — say the holder's machine died mid-edit — an admin can break it with svn unlock --force from a working copy, or svnadmin lslocks and svnadmin rmlocks directly on the server. You can also hook pre-lock and pre-unlock scripts to audit or restrict who may break locks.

Enforcing the property reliably

The catch: svn:needs-lock only protects files if clients actually set it. Client-side auto-props in each user's config are unreliable — a new team member with a default config can commit an unlocked binary and the read-only enforcement never kicks in. The robust approach is repository-side: use a pre-commit hook to reject binary files that lack the property, or set svn:auto-props in the repository configuration. Client config alone is not enough.

Trade-offs and limitations

Locking serializes work on a file, which is the point for binaries but a bottleneck if misapplied to mergeable text. Locks are advisory tokens tied to a working copy; committing with --no-unlock or abandoning a checkout can leave stale locks that an administrator must break manually. Also, Subversion is in maintenance-oriented maturity — evaluate long-term tooling and hosting support before adopting it for a new project.

What to do next

If you're versioning unmergeable assets, spin up a test repository, set svn:needs-lock on a binary file, and confirm the working copy becomes read-only until svn lock is run. Then try locking from a second working copy and verify the error names the owner. Many teams run a hybrid: source code in Git for its branching, binary art assets in a Subversion repository with svn:needs-lock applied via auto-props, so each tool plays to its strengths.