Versions and handoverPro

A show is worked on over weeks, by more than one person, and then handed to somebody else to run. These are the four things the file itself can tell you and do for you.

1. What the file remembers

Every save that changes the show writes a line into the file: who saved it, when, and what moved — the cues added, removed, edited and moved, and the settings that changed. Cuerunner ▾ → Show History… reads those lines back, newest first, with the detail of each entry behind a disclosure.

A save that changes nothing writes the same bytes back and adds no line, which is what makes a showfile safe to keep in version control: a show opened, saved and closed without an edit is the same file. A save also checks the file it is about to replace: if what is on disk is not what this window opened or last wrote — a colleague saved the show on the share — it asks whether to overwrite that file or to leave it alone and keep the show unsaved, rather than replacing an edit it never saw. A measurement the app took since the file was written — a file's length, the audible region inside it — is the one thing that can still change the bytes: it is not an edit, so it adds no line, and a show whose media was scanned between two saves compares as unchanged. Show files are not converted, so no save records one, and a file this build does not know is refused. The shape is declared and checked, and an older file — one that leaves out a settings section this build writes — is refused by name as it opens. A file remembers its last two hundred changes and lets the oldest fall off.

The history lives in the .cuerunner, so it survives being copied, emailed or handed over. It is written whether or not this machine is licensed — it is the show's own record of itself — and reading it back is free. What the key turns on is comparing this file with another and merging two people's work.

2. Comparing two versions

Cuerunner ▾ → Compare Show… takes another saved show and says what changed from it to the show on screen: the cues added, the cues removed, the cues edited with the fields that changed, the cues that moved, and the settings that moved with them. The file you pick is the older side, so read the heading as "what changed since this was written" — the version from last night's rehearsal against the one you are holding.

The comparison is about the show rather than about the machine: the audio file a cue plays is compared by the file's own name, so a show copied into another folder, or onto another machine, does not read as every cue having been edited.

3. Merging two people's work

Cuerunner ▾ → Merge Show… merges another person's copy of the show into yours, and asks for the version the two of you started from. That third file is not bookkeeping: with two files alone, "I changed this" and "you changed it" look the same, and a merge that cannot tell them apart throws one person's work away.

A cue one side changed is taken. A cue both sides changed in different fields is put together. A cue both sides changed in the same field is a conflict: the merge keeps one side's value and names the conflict — the cue, both values, and whose was kept — rather than deciding quietly. The order is this show's, with the other side's cues placed among the neighbours they were added after, and groups stay together.

What a merge will not pretend to do is said rather than guessed: the audio file a cue plays is this show's, because the other copy resolved its media on the other machine; a cue whose group went away comes back at the top level; and each of those is listed in the report.

The merge writes a new file and leaves both inputs exactly as they were, so it is safe to try twice. The report's second button runs the same merge over the same two files again with the other side's choices for the conflicts.

4. Handing a show over as one file

Cuerunner ▾ → Export Bundle… writes the show and every audio file it plays into one .cuerunnerx: a zip holding show.cuerunner and a media/ folder, with the showfile pointing inside it. It opens in any file manager, and its bytes are a function of the show, so two exports of the same show are the same file. A file the show names that is not on this machine is reported rather than failing the export.

Import Bundle… asks where the show should live, unpacks it there and opens it: the audio is in the folder beside the showfile, so every cue plays without anything to relink. If the folder already holds files by those names, the app asks before replacing them. A bundle whose contents do not match the checksums it carries is refused rather than half-unpacked.

A bundle carries up to about 4 GB of media — the zip format's own limit without its 64-bit extension, which this app does not write. A show bigger than that says so instead of being written as an archive that lies about its own contents; the .cuerunner itself has no such limit, and a show that size can still be moved by copying its folder.