This is a long one.. Apologies..
So, you produce a document or deliverable at work. If you regularly produce a document or deliverable at work, then this is for you.. Let’s talk version control.
First of all, let’s get some stuff out of the way:
> Why is this important?
Because, my friend, one day you’ll fuck it up, or you’ll be on holiday and somebody else will. Without version control, you’re stuck with the unenviable task of fixing your document up.
> Isn’t this just something coders need to care about?
NO! I have often been in a situation where someone has said ‘I like it how it was before. Can we change it back?’ of a presentation I’ve pulled together, or where a process has reverted to a previous iteration and the document has had to be pulled back a level. Without separate versions, that would have been a pain to pull together.
The point is that if you are developing a document, if it is subject to frequent revisions or refreshes, the environment you work in is open to change, or you are handing over your work to someone whilst you take a well earned break, you need a little version control in your life.
Behaviour
Before I rabbit on about how I like to version my documents I’d like to make one very brief point: knowing how to version documents is one thing, actually doing it is another.
Version control is just as much about how you think about your work as it is how you do it. Getting into the habit of re-versioning your files before you make changes to it is hard at first, but essential. It is good working practice and prevents you from accidentally overwriting your old work.
Ownership
None of the following works without the concept of a master document; one document that is the focus for changes or updates. Without it, people will make changes to whatever version of the file they can find and you won’t know what the real picture is.
Personally, I throw all of my documents onto SharePoint and the most recent version of the file on that site is considered the master. People know when I’m making changes to it because I check it out.
There are plenty of SharePoint alternatives out there, so have a nosey. By no means am I saying that this is the holy grail of solutions. In fact, I probably shouldn’t be using SharePoint for version control at all, but that’s another discussion in itself!
Two Kinds
In my experience there are two kinds of document that I work on.
The first is the kind of thing that I write and then build upon. This is my lego document. Bricks are piling on top of one another, being moved around, being removed etc.
The second is the kind of document that reflects a point in time, often reliant on data refreshes and the like. The data in the document changes depending on its source data, which can be different from day to day. I am not making changes or building on the content, I am just refreshing the contents. This is my diary document. It is a record of what happened on a particular day.
Lego!
These documents tend to be Word (translation: Pages) or PowerPoint (translation: Keynote) documents. I start with an idea and then work on it, adding stuff, deleting stuff, moving stuff.. This is iterative; I am building my document bottom up.
My versions, therefore, just need to reflect the iteration I am currently working on.
My personal rules for these documents are:
> The first version of the file is always suffixed by 0.1
> Each time I make a revision I increment this number (0.1, 0.2, 0.3 etc)
> The file only reaches a 1.x version once it has been reviewed (meaning I allow Apple-like versions, such as 0.15)
> A log of changes should be kept with, or close to, the document for reference
> Each version is uploaded to my SharePoint site as it becomes available (the master)
The diary
For me, Excel (translation: Numbers) tends to be my diary document. A half decent example of this would be a status tracker: You want to maintain an up to date view but also look back on previous days to see what the situation was then.
These docs get versioned according to the same philosophy as before. If I’m refreshing my data, I create a new version.
Personal preferences for these, as before:
> The title of the file is prefixed by the date in YYYYMMDD format (so that files order correctly in folders)
> If the file is built upon, the date remains unchanged, but a version number is suffixed (as before, with a change log, which should include details of any persistent changes required)
> Each version is uploaded to my SharePoint site as it becomes available (the master)
Over and out..
Of course, all of this is personal preference. Most, if not all, of the people who will read this probably have their own system for doing this already. If you’re reading this and you do, I’d love to hear what you do differently / what you think I could improve on.
*SVP means s’il vous plaĆ®t






