File Locking: The Missing Piece in Creative Collaboration

Why Binary Files Can't Be Merged

Code is stored as plain text. When two developers modify the same file, a version control system can compare the two sets of changes line by line. It highlights what each person changed and, in many cases, combines both sets of changes automatically. When it can't, it shows the conflict explicitly so a developer can resolve it manually.

Binary files have no equivalent. A Photoshop document is not a sequence of lines — it's a structured binary format that cannot be meaningfully compared byte by byte to produce a human-readable diff. A rigged character mesh in .fbx format has no “line 247” that can be merged with another version's “line 247.” A DaVinci Resolve project file, a Premiere Pro sequence, an Unreal level package — none of these can be merged.

The result is deterministic: whoever pushes last wins. The first person's work is overwritten. In a worst-case scenario, the first person does not discover this until hours later, when they pull the latest version and find their changes gone with no warning and no recovery path if the overwrite was not caught in time.

How File Locking Works in Cloudverest

Before editing a binary file, you lock it. This works from three places: the desktop app, the web UI, or the CLI.

From the CLI, the command is straightforward:

• cvt lock characters/hero.fbx — lock a single file
• cvt lock textures/hero_diffuse.psd — lock a texture before editing
• cvt unlock characters/hero.fbx — release when done

From the desktop app and web UI, you right-click a file and select lock. The file immediately appears as locked to every other team member — showing your name, your avatar, and the time the lock was taken. Anyone who tries to lock the same file sees the existing lock owner and knows the file is in use.

The lock does not prevent others from downloading or reading the file. It only signals that an edit is in progress and prevents a second person from taking their own lock — which is the clear indication that they should not start editing.

Auto-Release on Disconnect

A file locking system is only useful if locks eventually release. A system where files can be stuck locked indefinitely — because an artist locked a file on Friday, closed their laptop, and went on holiday — is worse than no system at all. The team either has to wait or manually break locks, both of which introduce friction and frustration.

Cloudverest releases locks automatically when the desktop app closes or the connection drops. If an artist's machine crashes mid-session, the lock is released within seconds. If the VPN disconnects, the lock releases. No manual intervention needed from a team lead or administrator.

For teams that want additional control, an administrator can manually release any lock from the web UI — useful if an artist is unavailable and their lock needs to be cleared urgently. But in practice, the auto-release covers the vast majority of cases without requiring any manual action.

Who Can See What's Locked

Lock visibility is shared across the entire team in real time. The web UI and desktop app both display a live view of every currently locked file in the project — who holds each lock, on which branch, and since when.

This is not just about preventing conflicts. It's about coordination. An artist checking the lock view before starting their day can see at a glance which files are actively being worked on, which team members are mid-session, and which assets are available. There are no surprises mid-session — you know before you start editing whether the file you need is free.

Lock notifications are also available. If you're waiting for a colleague to finish with a file, you can subscribe to a notification and receive an alert the moment the lock releases. No need to keep checking manually or interrupting a colleague to ask if they're done.

When to Use Locking vs Branching

File locking and branching solve different problems. Understanding when to reach for each one makes both tools more effective.

Use file locking for short-term, focused edits on a single file or small set of files. You're correcting skin weights on a character mesh. You're making a color correction pass on a texture sheet. You're trimming a section out of a video file. The edit takes minutes to hours. You lock, edit, push, and release. The lock communicates to your team that work is in progress on that specific asset right now.

Use branching for longer work streams where you're making changes across multiple files over days or a full sprint. You're building a new character from scratch — meshes, textures, rigs, and animations all changing in concert. You're redesigning a game level across multiple map files. The branch isolates all of that work from main until it's ready to merge.

In practice, you use both together. Work on your feature branch, and lock files within that branch while you have them open for active editing. The branch protects the rest of the team from unfinished work. The lock protects your own branch from a teammate accidentally editing the same file you're currently working on.