Video project version (& patch) management at DVinfo.net

David Esp · January 10th, 2010, 03:46 AM

What is a good structuring convention and naming system to cope with versioning and patching of multiple items of media in a structured project?

For example, when developing a non trivial video project, I arrange it as a structure of nested sequences. When I find a problem in a lower-level (in this structure) sequence, there are various ways to fix it, leading to either a full version change trickling upwards in the structure or else some kind of patching e.g. so only the fixed bits of sub sequences need be rendered.

To minimise opportunities for chaos, I have been evolving an organized working practice for handling these kinds of practical situation. This practice involves a vocabulary of terms and a standard system of naming/identification for project assets (sequences/clips etc.). For example Sequence A1 uses (bits of) Sequence B1, then if I modify B1 (e.g. levels-fix) then it becomes B2 hence A1 becomes A2 (since it doesn't look the same when you play it). Then as deadline approaches I see another problem in B2 and fix it, giving B3, but no time to render it all into a single tidy item, so only render sub-parts of it e.g. B3Part1, B3Part2 then put these in sequence A2 (e.g. on an opaque track above the others, which I call a sur-track as opposed to a sub-track) giving A3(Patches). The "(Patches)" designation is to highlight it as something that ideally should be replaced by a tidier (full render of B-sequence to a single item) version at a later time. Or at least, to warn anyone pulling it out of an archive what to expect. Pragmatics.

I realise that some NLEs (and their add-ons) and central repositories etc. handle things in a way that automates some degree of this management, but even then there is the question of how best to use these systems. Actual projects may be split between more than one NLE type, let alone instance, and the "central repository" might sometimes only be a directory (folder) structure, so it would be good to have a solid process "in the tool bag".

On the assumption that I have almost certainly been re-inventing the wheel here, I did some web-searching, e.g. on the terms [video rendering patching versions] and again on terms such as [video patch "version management"]. Nothing relevant came back.

So my question, where are all the wheels? I wonder if there is an existing industry-standard system or any material, on-line or books, on this subject. Looking for a general work procedure, not tied to any particular tools but adaptable to any combination of them.

January 10th, 2010, 03:46 AM	#1
David Esp Regular Crew Join Date: Apr 2007 Location: Alton in Hants and Swanage in Dorset, UK Posts: 45	Video project version (& patch) management What is a good structuring convention and naming system to cope with versioning and patching of multiple items of media in a structured project? For example, when developing a non trivial video project, I arrange it as a structure of nested sequences. When I find a problem in a lower-level (in this structure) sequence, there are various ways to fix it, leading to either a full version change trickling upwards in the structure or else some kind of patching e.g. so only the fixed bits of sub sequences need be rendered. To minimise opportunities for chaos, I have been evolving an organized working practice for handling these kinds of practical situation. This practice involves a vocabulary of terms and a standard system of naming/identification for project assets (sequences/clips etc.). For example Sequence A1 uses (bits of) Sequence B1, then if I modify B1 (e.g. levels-fix) then it becomes B2 hence A1 becomes A2 (since it doesn't look the same when you play it). Then as deadline approaches I see another problem in B2 and fix it, giving B3, but no time to render it all into a single tidy item, so only render sub-parts of it e.g. B3Part1, B3Part2 then put these in sequence A2 (e.g. on an opaque track above the others, which I call a sur-track as opposed to a sub-track) giving A3(Patches). The "(Patches)" designation is to highlight it as something that ideally should be replaced by a tidier (full render of B-sequence to a single item) version at a later time. Or at least, to warn anyone pulling it out of an archive what to expect. Pragmatics. I realise that some NLEs (and their add-ons) and central repositories etc. handle things in a way that automates some degree of this management, but even then there is the question of how best to use these systems. Actual projects may be split between more than one NLE type, let alone instance, and the "central repository" might sometimes only be a directory (folder) structure, so it would be good to have a solid process "in the tool bag". On the assumption that I have almost certainly been re-inventing the wheel here, I did some web-searching, e.g. on the terms [video rendering patching versions] and again on terms such as [video patch "version management"]. Nothing relevant came back. So my question, where are all the wheels? I wonder if there is an existing industry-standard system or any material, on-line or books, on this subject. Looking for a general work procedure, not tied to any particular tools but adaptable to any combination of them.