on the Kdenlive irc channel, I asked:

"Has anyone given consideration to how multiple editors can best use kdenlive to collaborate on the cut of a film?"

"I am assuming that xml in the .kdenlive file is storing an edit decision list. Is that right? It includes ONLY pointers to the source material. Right? Would it make sense to manage that file under version control, with branching and such? What would it look like to merge another's change set into the master branch? Is this the right tool to be considering these questions for?"

The minimum viable product for this feature request would be a merge work flow suitable for a film editor working in an edit suite all day, and perhaps unfamiliar with the command line. An editor ought to be able to slug in a few frames for a sequence, dispatch that sequence to a collaborator, later examine a branch of the main project representing the collaborator's work, and choose to accept or reject each of the proposed edit choices while merging it back to the mainline.

This proposes a visual diff, alongside a code diff, perhaps some auto-scaling of the display to accommodate additional tracks, with clear visual markers about when tracks shared by both branches under examination diverge, and resynchronize, with the ability to drill into and investigate those changes in detail.

My first question would be 'what would a merge look like?'

I'm guessing two monitors side-by-side, with convenient means for muting audio from either feed as desired, or mixing them, perhaps one playing in the left ear, the other in the right, with a screen showing the plain text diff in the EDL, the viewport on the EDL advancing with the head on the time line, with the diff filling in the holes with black room tone if available, silence if not, and showing the change, in context, and side-by-side, with an easy means for accepting or rejecting each change or small group of changes as they are encountered on the time line. This process might be facilitated by the use of a time code on a version'd rendered result, to help orient and provide context for examining the diffs.

Thinking specifically about the sound design of a project, I would anticipate that the audio engineer is going to hand me back more tracks than I had provided. Perhaps mine are simply labeled, if they have not already been, and muted, the new ones added and made active by un-muting them. If a J-cut or L-cut is called for in the sound design, I can imagine that would require some occasional adjustments to cover them in the video.

So, ideally, I'm thinking a dashboard and merge work flow which would facilitate a real collaboration in the film editing environment, as we experience as developers, the ability to branch, test ideas in isolated environments and merge what works back into the main line of development.

I imagine the time line being used to provide visual clues about what tracks belong to which branches, and when a track diverges between the branches under consideration, that we would see that branching visually on the time line for that track.

Changes ought to be accepted a commit at a time (cherry-pick), or a change-set-at-a-time (merge the entire branch).

I would place under version control the *.kdenlive file, but the heavy unchanging binary source material should not need to clutter the repository.