Version Control: Managing document revisions

When you are working on documents, version control (aka revision control) can be pretty important. I find it’s very helpful, particularly when you’re sending multiple drafts to multiple people, to label revisions so everyone knows they are looking at the latest and greatest version. Otherwise, if you just keep the filename the same and send it out again, it can become quite confusing.

While electronic tools are available to help manage version control for things like software development projects, I have an easy, free filenaming system that accomplishes the same thing and which you might find useful.

When I first create the document, I include all of the important information in the filename that I might need to identify/find it in the future.

1. ID Tag

The first part of the filename includes a designation that I use for easy identification. I might write grants to the same foundation for multiple clients, or generate similar documents for more than one organization, so tagging the file with a consistent identifier helps me to keep them all straight, particularly when things end up on my desktop. I like to use a 2-4 letter ID in all upper case: e.g., RR for the City of Round Rock.

You could also use a second ID tag to differentiate between similar, but different documents that belong to the same client, project, etc.

MC                for the City of Mid City

MC CHD       for documents pertaining to the Mid City commercial historic district

MC FHHD     for documents pertaining to the Mid City Frog Hill Historic District

2. Description

The second part of the filename describes the document and, in some cases, who it is intended for. For instance:

MC CHD Map of NR historic district.pdf

3. Date

I also include a date for easy reference. For projects like surveys, which are conducted infrequently, the year is sufficient. For grant applications, I include the month and year so that I can easily see when the grant was submitted. Anything mailed or published should be named with the mailing or publication date. Here are some examples:

MC 2012 Historic Resources Survey Map.pdf

MC Big County Fndn grant app March 2012.docx

MC CHD Letter to property owners 06.01.2012.docx

4. Revision Number

Version control is very important, and this is the system that I have come up with for managing revisions.

I add or update revision numbers only when I make a change AND I am releasing the document for review. If I make multiple rounds of edits (over the course of a week, for example) but have not released the document, all of those changes would be made under the same revision number.

Let’s use an example in which my original document (for the Very Small Town project) is named

VST Landmark report.docx

I have been working on this report for a while, but I use the original filename the whole time. After I send out the first draft for review and it comes back, I need make revisions. I want to keep an electronic copy of the original version, in case I need to refer back to it, but I need to know which is the original and which is the new version.

When I’m ready to make revisions, I “save as” and add “-rev1” to the end of the filename. For example:

VST Landmark report-rev1.docx

This is the name of the file that goes back out to my client the next time. If they send back more comments that require revision, or if I make additional changes after I have released this document, I update the version number to –rev2.

5. Reviewer’s Initials

You may go through quite a few revisions, and it is not anyone else’s job to manage version control – as long as you are maintaining the filenaming conventions, you will be able to reference changes at any point in the process, as needed.

If I ask people to send me feedback, sometimes they will rename the file entirely. If that happens, I keep the file that they returned to me as named by them, but I also create another copy of the file with the correct name and add their initials to the end of the filename, like so:

VST Landmark report-NP.docx
or
VST Landmark report-rev4-NP.docx

6. The Final Version

Once the document is final and has been published, I go back and add the word “final” to the filename of the last version.

VST Landmark report-rev4-final.docx

(Note: Don’t add the word “final” too early! Otherwise you can end up with multiple “final” versions as changes continue to be made.)

I don’t take out the revision number, because I still need that for my own reference, but I will also save a final version for the client that does not include a revision number. It’s a good idea to add/update the actual publication or mailing date at that time.

VST Landmark Report June 2012.docx

7. Wait a minute! How do you deal with all of those different versions? Doesn’t that turn into a mess?

I manage my files in folders, so (for example) all of the Landmark Report versions would be together. Visually, that’s easier for me to deal with. Eventually, I archive (but don’t delete) all by the final versions of things, to keep my files cleaned up and easy to find.

Comments are closed.