D
01-16-2009, 04:09 PM
I have my own version control system, and I use version control for a number of reasons. Clearly, since changes are only saved as a whole in files, and not the change stack, I save frequently to versioned files to maintain restore points.
Everyone has run into that one situation (or more often) where you've made a series of changes that have totally obfuscated what you were trying to achieve. Now, two hours ago, you had something that was pretty damn close to perfect, but this is just one of those times when you're drawing a blank as to what exactly you had in your insert chain that made that magic. It's nice to be able to go back to that, or something close to it.
Another reason I use versioning is file corruption. This has only happened to me once, but I lost a considerable amount of work, as I hadn't been adhering strictly to my system: there are pluses and minuses to both adherence and occasional non-adherence, and learning to tell the difference is a matter of personal experience, and the more experience you have, the better your judgment call.
In the end, it's a crap shoot anyway, and despite all your best practices, you might lose that magic mix you had just three hours ago. However, if you practice good versioning technique, you won't lose as much as if you don't. I usually end up with as many as 300 npr/cpr files at the end of production. Chump change, really.
My personal technique is simply a file naming system: name_of_song_0.1a.npr/cpr and bumping the letter every 15 minutes or so, or every x minor changes or adjustments. If I make some major changes, i.e. rendering VSTi tracks, then I bump the minor version numeric one, and everything after it resets, i.e. name_of_song_0.2a.npr/cpr and so on. Pretty straightforward once you establish a system.
This has been a system I've developed or adapted from other systems over the past 28 or so years in the computer industry, from designing game engines for the TRS-80 and ATARI in assembler code in the late 70's to 3D and graphic design and network administration.
Anyway, I'd be more than pleased to hear of anyone else's version, and/or loss control systems.
Everyone has run into that one situation (or more often) where you've made a series of changes that have totally obfuscated what you were trying to achieve. Now, two hours ago, you had something that was pretty damn close to perfect, but this is just one of those times when you're drawing a blank as to what exactly you had in your insert chain that made that magic. It's nice to be able to go back to that, or something close to it.
Another reason I use versioning is file corruption. This has only happened to me once, but I lost a considerable amount of work, as I hadn't been adhering strictly to my system: there are pluses and minuses to both adherence and occasional non-adherence, and learning to tell the difference is a matter of personal experience, and the more experience you have, the better your judgment call.
In the end, it's a crap shoot anyway, and despite all your best practices, you might lose that magic mix you had just three hours ago. However, if you practice good versioning technique, you won't lose as much as if you don't. I usually end up with as many as 300 npr/cpr files at the end of production. Chump change, really.
My personal technique is simply a file naming system: name_of_song_0.1a.npr/cpr and bumping the letter every 15 minutes or so, or every x minor changes or adjustments. If I make some major changes, i.e. rendering VSTi tracks, then I bump the minor version numeric one, and everything after it resets, i.e. name_of_song_0.2a.npr/cpr and so on. Pretty straightforward once you establish a system.
This has been a system I've developed or adapted from other systems over the past 28 or so years in the computer industry, from designing game engines for the TRS-80 and ATARI in assembler code in the late 70's to 3D and graphic design and network administration.
Anyway, I'd be more than pleased to hear of anyone else's version, and/or loss control systems.