The power and fun of having versioning

Ah versions, the poor cousin of the revision, much maligned and all too often ignored.  Versions are the workhorse of the Vault system, every time we do a check in, be it a regular update during the day, an end of day "just in case" check in, a rename, property update or a state change, versions are there, working in the background to make sure we capture the design evolution and work in progress milestones.

In addition to being ignored, they are becoming scarcer, we don't create them as frequently as we used to, operations that create new parent versions like rename, move etc are deferred to coincide with other updates meaning we are creating less – we don't even create whole new files for document versions any more.  When making a purely cosmetic change that doesn't directly affect the file we just share the same file across versions.  Add the purging of "non-essential" versions and it seems we are squeezing them right out of the picture.

But before we get carried away lets celebrate a few of the versions greater virtues – where would we be 5 minutes before the design deadline when you realise you changed the wrong file?  What about 3 months later when the boss changes his mind about the project "direction" or you just simply need to figure out who to blame for all that has gone wrong in your world?

In trouble, that's where – versions allow us to go back in time, whether to recover unintended changes, to revert to previous design iterations and with copy design enable design branching or simply find out who made a version.  It captures through comments and visual comparison tools the design iteration and intent and perhaps most importantly lets us know who it was that made the changes.

Versions are a wealth of important incremental design data and the foundation of real document control, spare them a thought next time you are about to hit the purge button or complain there are too many of them hanging around.

-Allan