How to Avoid DaVinci Resolve Project Lock Conflicts When a Colorist and Editor Share a Timeline

There's a specific kind of dread that sets in when you open a shared Resolve project and see the little padlock icon next to a timeline someone else is already sitting inside, and you know that whatever you were about to do, whether it's a quick trim or a full pass of secondary grading, is going to have to wait, or worse, is going to collide with changes that person hasn't pushed yet. We hear about this constantly from colorist and editor pairs working remotely on the same project, and it's one of those problems that seems small until it costs someone an entire afternoon of redone work because two people were both convinced they had the current version.

Why Resolve's locking model breaks down the moment you're not in the same building

DaVinci Resolve's collaboration mode was genuinely built for shared-database setups where everyone's on the same network, hitting the same PostgreSQL instance, and bin locks and timeline locks resolve themselves in real time because everyone can see who's editing what. That model works fine in a facility. It gets shaky the moment your colorist is working from home on one coast and your editor is cutting from a different city entirely, because now you've got latency, dropped connections, and the very real possibility that someone force-quits Resolve mid-session and leaves a lock hanging that nobody remembers to release. We've talked to colorists who've lost a full grading pass because an editor's connection dropped while a bin was locked, and Resolve just kept the lock active for hours until someone manually intervened.

It's also worth being specific about a detail a lot of remote teams miss, DaVinci Resolve's actual Collaboration feature requires Resolve Studio and a proper PostgreSQL database that everyone connects to over the network, which is a real piece of infrastructure most two- or three-person freelance teams never bother setting up. What ends up happening instead is a Resolve project file gets stored on a synced Dropbox or Google Drive folder, and both of those sync services were built for documents and photos, not for a live database file that two people might have open at the same time, so the "lock" you're relying on is really just whichever sync client finishes uploading first, which is a much flimsier guarantee than an actual database lock and explains why so many teams find themselves with two competing copies of the same project sitting in a conflicted-copy file nobody wants to open.

The real cost isn't the lock, it's what happens around it

Here's the thing people miss, the lock itself is actually doing its job most of the time, it's preventing two people from literally overwriting the same clip attributes at the same instant, which would be a genuine disaster. The actual cost is everything that happens around the lock, the editor who can't get in because the colorist forgot to release a timeline lock before logging off for the night, the colorist who grades an entire scene only to find the editor made picture changes upstream that weren't communicated, and now the grade has to be reconformed against a timeline that's shifted underneath it. At the end of the day, project locking is a symptom, the actual disease is that colorist and editor don't have a shared, timestamped source of truth for who touched what, and when.

The classic overwrite scenario

Picture this, an editor tightens a scene on a Tuesday afternoon, trimming four shots and adding a new insert, and doesn't tell the colorist because it felt like a small change. The colorist, working that same evening from a stale local copy of the project, grades the old version of the scene and pushes it back. Now you've got a grade sitting on shots that don't exist in the current cut anymore, and reconciling that means either the colorist redoes the work or the editor has to manually reconform grade nodes onto the new edit, neither of which is a fun way to spend a Wednesday.

Building an actual handoff protocol instead of hoping for the best

The fix here isn't a Resolve setting, it's a process, and we tell every colorist and editor pair we talk to the same basic structure. Whoever has the project checks it out explicitly, works their pass, and pushes it back with a clear note on what changed, rather than everyone assuming they can just open the project whenever they feel like it. This sounds obvious written down and it's shocking how often teams skip it because everyone's in a hurry.

The third step is where a review tool earns its keep, because instead of the editor and colorist arguing over whose local Resolve copy is "current," you push a fresh export to a shared review link every time either of you finishes a meaningful pass, and that becomes the actual source of truth both of you, and the client, can point to. We built this into PlayPause because we saw teams treating the Resolve project file as the single record of progress, when it should really be treated as a working file, with the review link acting as the checkpoint everyone agrees on.

Using version history as your actual paper trail

One thing that consistently saves teams here is keeping every pushed version inside one running review thread rather than a scattered mess of "v2_final," "v2_final_colorist_pass," and "v2_actually_final" files sitting in a shared drive somewhere nobody fully trusts. When an editor uploads a new export to PlayPause, it sits alongside the colorist's previous pass with a visible timestamp and version label, so if a lock conflict does happen, at least there's zero ambiguity about which version is newer and who touched it last.

This is also where version history inside a proper review platform beats a shared folder, because a folder full of similarly-named files tells you nothing about intent, while a versioned review thread with comments attached tells you exactly what each pass was trying to accomplish and whether the client or the internal team actually signed off on it.

Communicating changes before they become conflicts

A big part of avoiding lock conflicts is just talking before you touch the timeline, and this is where a lot of remote colorist and editor pairs underinvest, assuming Slack messages or a quick text will cover it. In practice, those messages get missed, especially across time zones, and the safer habit is attaching your notes directly to the actual footage inside a shared review space rather than a chat thread that scrolls away. We see this work well when editors leave a comment on the specific clip or scene they just touched, timecoded to the exact frame, so the colorist opens the project already knowing what changed before they even scrub through it. If you're also managing the moment where a client needs to weigh in on cut decisions before the colorist even starts grading, our piece on getting client approval on Final Cut Pro multicam angle choices covers a related version of this exact same coordination problem, just one step earlier in the pipeline.

• One person owns the project file at a time, agreed explicitly
• Version notes describe what changed, not just that something changed
• Fresh review export pushed after every meaningful pass
• Locks released the moment a session ends
• Comments attached to timecoded footage, not buried in chat

When It's Two Colorists Splitting the Same Project, Not an Editor and a Colorist

The same conflict shows up in a slightly different shape on bigger jobs where two colorists split reels on the same feature or series, dividing episodes or scenes between them to hit a deadline neither could hit alone. The failure mode here is subtler than an editor changing picture underneath a grade, because both people are working inside color, so a stale lock or a missed sync can mean two colorists independently developing slightly different looks for scenes that are supposed to cut together seamlessly, and nobody notices until a supervising colorist or the DP watches a reel end to end and the color shifts oddly at a scene change that was never actually a scene change creatively. The fix is the same explicit-ownership discipline, but it needs one more layer on top, a shared reference still or a locked LUT both colorists are grading against, so even if the project-locking mechanics behave perfectly, the actual look stays consistent across two people's independent passes.

What to do when a lock conflict has already happened

If you're reading this because it already happened to you, the honest advice is to stop trying to merge the two divergent versions manually inside Resolve, because reconciling two grading passes on two different edit versions is almost always slower than picking the more current cut and redoing the grade on top of it cleanly. Pull the latest edit, confirm it with the editor directly, and re-apply your grade decisions from there, using your node structure and saved stills as a reference rather than trying to force the old timeline to match. It stings to redo work, but it's faster than untangling a corrupted project database, which is a much worse afternoon by any measure.

Where this fits into the bigger delivery picture

Lock conflicts are really just the collaboration-layer version of a problem that shows up again later at delivery time too, which is that Resolve itself was never designed to be the thing a client, or even a second internal team member, interacts with directly. Groups like the Motion Picture Editors Guild have written about how much modern post workflows depend on tools outside the NLE to keep teams synced, and that's exactly the gap PlayPause is built to close, letting the editor and colorist keep Resolve as their actual working tool while using a shared review layer for handoffs, client updates, and version history that nobody has to reconstruct from filenames. Once you've got the process sorted internally, the next question is usually how you hand the finished project to a client who doesn't even have Resolve installed, which is exactly what we cover in our guide to packaging a Resolve delivery for clients without Resolve.

Stop letting the padlock be your only safeguard

A padlock icon in Resolve is a decent last line of defense, but it was never going to be your whole collaboration strategy, and teams that pair explicit ownership handoffs with a shared review checkpoint stop losing afternoons to overwritten grades. If your colorist and editor are still fighting over the same project file with no shared source of truth in between, it's worth setting up a proper Video Review checkpoint through PlayPause so every pass gets logged, timestamped, and reviewable before the next person touches the timeline, and comparing PlayPause pricing against the cost of even one lost afternoon of redone grading.