Graduate Student Success Coaching

Document Version Control. Never Lose Documents Again!
Digital Organization Part 3

Document version control is a headache for many students. It’s a skill that grad. students are assumed to have, but outside of computer programming, is rarely taught. No matter what type of files you need to store, use these version control tips to save you time and aggravation.*

If you are losing time looking for the right version, have a quadrillion versions because you’re worried about losing something, are struggling to incorporate different people’s edits across multiple documents, or are procrastinating on a task because finding the information you need involves searching across multiple files, this article is for you.

*I am not a programmer, version control in computer programming is a specific beast. If you’re looking for programming source control, check out Git.

This is Part 3 of the Digital Organization Series for Grad. Students
Part 1: Folder Organization | Part 2: Email Organization

Document Version Control Principles

I’m going to teach you the methods I use to never lose documents and never waste a second wondering if I’m opening the right document version. It works because it revolves around the main purposes of document control:

1. making using the correct version of the document error-less and effortless,
2. allowing reconciliation across documents (e.g., feedback from multiple people or tracking an error across versions),
3. and maintaining a record of variations in case you need information from a prior version

Using the Correct Version in Document Control

Who doesn’t want to spend less time searching for the most current version of the document they’re working on? This is the primary purpose of document version control and it’s one of the easiest to address.

There are a few simple steps you can take to make sure this doesn’t happen. They involve three factors: file naming, numbering, and storage.

1. File Naming Rules

1. Make file names clear and descriptive. For example, it’s not Assignment_3, it’s Hist305_A3_FallofRome. “Assignment_3” could refer to version three or assignment number three. In the revised name, it’s clear that this is assignment 3 for the History 305 class, and it’s about the fall of Rome. This reduces the chance of version control confusion. and makes it easier to find in the distant future when you’ve forgotten which class you wrote the Fall of Rome essay for.
   
2. Don’t use numbers at the end of a file name unless they are a version control number. This keeps the version number prominent, saving you time when you’re trying to find the file you want to open.
   
3. Don’t use dates as version control numbers. DrCG_PrevofDep_080923 might seem like a good idea, but it’s easy to mistake this for DrCG_PrevofDep_030923 and start working on the wrong version. Plus, date formatting can affect computer sorting making it harder to organize (e.g., 09_09_23 may be the same date as 9_9_23 but it won’t sort that way).
   
4. Add the word “Final” only to officially submitted versions. I don’t mean versions you submitted to your advisor for feedback, I mean versions that were submitted to their final destination. For example, the version that went to your instructor for a grade, the version of your thesis or dissertation that was submitted to your university for archiving, or the version you submitted to the journal for publication. Until it’s formally submitted, don’t assume it’s final.
   
5. Add initials to the end of the file name on feedback versions. When you provide feedback, keep the sender’s file name but add an underscore and your initials to the end (or your full name if you share initials with a collaborator). Ask your collaborators to do the same. If you receive feedback without the reviewer’s initials, rename the file to include the initials when you save it. By keeping the original file name, it’s clear which version was reviewed (e.g., DrCG_PrevofDep_v4_jd means J.D. reviewed version four of the DrCG_DrCG_PrevofDep document).

2. Version Numbering Rules

Many students end up with a million versions because they are unclear about when to give a version a new number. Here’s how I do it.

1. Keep the version number the same when:
   • Changes are minor (grammar, typos, formatting, and style edits)
   • Deleted content is minor (a sentence here and there or only incorrect information has been removed)
   • Regardless of how much new information is added
2. Advance the version number when:
   • A large part of text/tables/figures has been removed and not saved otherwise [more on this when we cover maintaining a record]
   • Feedback from collaborators has been incorporated (prevents multiple reviews of the same version number)

This system ensures that deleted materials are retained in old versions without creating a million versions.

3. File Storage
(see Part 1 of this series for more on file storage)

Keep a subfolder for old versions in the project folder. When I was a researcher at a large non-profit, we called it the Bones folder. Keeping a separate folder for old drafts is another barrier to working in the wrong file. When you create a new version of the document you are working on, immediately move the old version to the Bones folder.

Reconciling Multiple Versions

One of the reasons that I prefer Microsoft Word or Open Office Writer (free open-source office suite) to other word processing programs is the ability to combine feedback from multiple authors into a single document. While Google Docs is a great collaborative tool, it is not a comprehensive word-processing program (yet). Between Word’s and Writer’s growing ability to do real-time collaboration and both programs’ ability to compare and combine multiple versions, they make version control much easier (Instructions: Word and Writer). When I reconcile feedback into one document, I always give it a new version number so that I am not overwriting the source version that the feedback was provided on.

Maintaining a Record of Changes

One thing I do to simplify version control for Word documents (or Writer), is to use comments to retain text and record changes across documents. This is even more vital for programs, like Google Docs, where changes are saved regularly, overwriting your working version. Let’s say I want to remove a paragraph in my methods but might need to use some of that text later. Instead of creating a new version to retain the text that would be deleted, I could add it to a comment in the document instead. This would save the text across future versions without needing a new version number.

You can also use comments as a way to indicate changes you made in response to feedback, which will help speed up future reviews from those collaborators as they can quickly see how you addressed their feedback without having to reread the entire section.

Finally, use comments to indicate major differences in code versions. For example, if I write SAS code that runs a model using listwise deletion and then later I run another version that uses pairwise deletion, I’ll use comments to note the differences. It can be easy to forget which version is which and the file name will get too long if I try to document the differences there. Plus, one program might have multiple model syntaxes with subtle differences across them. So, use comments to quickly identify variations in code across files and link them to the output (e.g., use a comment in the manuscript draft for a table or figure noting which file the code to run that data is in). You don’t want to be looking across multiple statistical files, reading the actual code to figure out which version was used months ago to produce the data in a given table. Good guidance on writing code comments can be found here.

Summary

I hope that you’ve found this digital organization series for graduate students helpful. Setting up systems early on can save you time, effort, and even heartache. If you have organization tips, please share them in the comments so that other students can learn from your ideas.