The absolute basics of version history

Likely one of the most useful tools within SharePoint is version history. It gives you a running list of the changes that have occurred in your files over their lifetimes. Specifically, version history gives you access to old copies of your files and shows you the number of each version, the size of each version, as well as who created each version and when.

Maybe you think the backup tool your organization uses on your shared drives is already good enough? That you’d never need something different? Think again. Below I go into very real examples of when many shared drive backups will fail to meet your needs, potentially causing hours of rework that you’d otherwise never have to do if—you guessed it—you were using SharePoint from the beginning.

Version history is generally used in two ways:

  1. Plain old version history: Getting shear joy out of having old versions of your files saved and stored in SharePoint so you can compare the current version to older copies (great for getting context of changes or current state), keep track of who made what changes (or who’s been in your file), and/or to restore old versions if the current one is bad, screwed up, or just overly regrettable. Basically it’s a nice, simple, user-friendly backup and auditing system. And it doesn’t require IT’s help to use.
  2. A robust release system: Version history lets you publish your documents in a way not unlike how software is released. The version number means something, access to different types of drafts are limited, and your documents are heavily controlled. This system is extremely useful in a corporate atmosphere, but also more complex to set up and maintain.

I’m only going to talk about the run-of-the-mill version history uses—item 1 above—in this post. In a future post, I’ll discuss how to use the version release system in your organization. And if you’d like to understand these concepts in video format (you know, the way of the future), have a peek below.

 

Why version history is useful

If your organization uses shared drives as its main method of storing and sharing files, you may have noticed—potentially in a fit of pure panic—that there’s no really easy way to get a hold of an old version of your file if something goes wrong. You’re at the mercy of the backup timer, which likely does a daily job at, say, midnight, to store and back up your files.

 

If you’re really lucky, your IT department backs up more frequently. One past employer of mine actually backed up shared drives every hour on the hour and saved those files for a day. Then it saved a daily backup (say, every night at midnight) for a week, and a weekly backup (say, from Sunday night) for a month. But most places don’t do this. It’s huge on resources, both people and space.

 

It’s also not as useful as it sounds. If you have an hourly backup option, and you do a lot work on a file in that hour, then you mistakenly save over your file, you’re stuck with whatever was backed up at the last one-hour mark, regardless of how many times you saved the file during that hour. You could be losing a ton of productivity with one mistaken click.

 

So, while your shared drive backups offer value, its arbitrary and based on when your IT department set up its systems to auto-backup. You don’t know how long those backups last, it may not be documented when they actually occur—on the hour, half hour, midnight, when?—and you may have to put in a trouble ticket to even gain access. Sounds unreliable.

 

SharePoint offers version history, which creates a new version of a file 1) every time you save your file, 2) every time you check in a file, 3) overwrite an existing file, or 4) if you’re co-authoring, every half hour after someone starts editing a file.

 

Why is it better? Versions are created when you think they should be. No more dependency on the system to backup for you. And you can jump back and view any historical version you’d like. You can even restore an old version, completely overwriting the current one. (And, if you regret making that decision, you restore the last version over the restoration! So meta!)

 

Version history gives you control over the lifespan of your files, allows you to see who’s been in them, and provides you the opportunity to fix mistakes.

 

How version history works

Make sure it’s enabled first

Be sure that version history is enabled in your document library. Unfortunately, version history is disabled by default in a brand new document library in SharePoint 2013. As of late 2015, a new document library in SharePoint Online, thankfully, has version history enabled.

 

That said, it’s your responsibility to check to make sure that version history is enabled in your document library. Don’t just assume! Here’s how: if you see the Version History options shown below, it’s on.

version history - Two ways to determine whether version history is on

Two ways to determine whether version history is on

 

 

When versions are created

Versions will be made whenever you perform one of the following actions:

  1. Save the file (client app): When you open a file in the client application—so, not Office Web Apps (OWA) or Office Online (OO), which are in the browser—and click the “Save” button in that application, a new version will be created.
    1. As an example, if you open a Word document in the full Word app, a new version is created each time you press the “Save” button in Word.
  2. Edit for thirty minutes (browser app): Every thirty minutes after you start editing an Office file in OWA/OO, a new version will be created. Because there’s no “Save” button in OWA/OO, there’s no intuitive way to force-create a version. If you want to force-create a version, you’ll want to close OWA/OO (don’t worry, your changes are automatically saved, they’re just not in a new version yet), check the file out, then check it back in immediately.
  3. Overwrite a file: When you upload a file with the same name as an already-existing file in the document library. Rather than completely overwriting the file, it creates a new version of it.
    1. For example, if you upload a file called “Movie1.mp4” and your library already has a file by that name, SharePoint will ask you if you want to replace the file. If you indicate that you do, it will create a new version of that file, even if it’s a completely different file.
  4. Check in a file: Checking in a file after checking it out will create a new version; even if you don’t make any changes, you still are given the option to create a new version.

 

How many versions are saved

The number of versions that will be saved depends on the system you’re using and the settings of the library you’re saving to.

 

According to Microsoft, SharePoint 2013 and SharePoint Online (Office 365) have the following limits:

  • Major versions: Microsoft suggests not saving more than 400,000 versions. After that, opening, saving, deleting, or viewing version history may not work. (Read: “Try it at your own risk.”) God help you if you ever find yourself in need of keeping 400,000. If that’s the case, I’ll be there’s a lawyer involved somehow.
  • Minor versions: Up to 511 minor versions are allowed. That’s a hard limit and you can’t go beyond it.

That said, when you enable version history in a library on-premises (so, SharePoint 2013), it doesn’t input a numerical limit, so it’s essentially infinity. A library in SharePoint Online, on the other hand, automatically inputs a limit of 500 major versions to start off. In both systems, this value can be changed by the site owner.

 

I’m sure the reason for no limits in on-prem is because Microsoft doesn’t care how much space you use on your own system; but they don’t want you going absolutely crazy on their system, “wasting” their space. At least that’s what makes sense to me. And considering the version limit was 100 back when I used to use SharePoint 2007, them starting at 500 is actually pretty nice.

 

(SharePoint 2010 supports 400,000 major versions as well; no word on minor version limits. A similar source for SharePoint 2007 doesn’t indicate limits on version history.)

 

Now, just because these numbers are all so high doesn’t mean you should start making versions willy-nilly. Your site owner could—for very legitimate reasons or, sometimes, for completely arbitrary ones, including not knowing any better—change the maximum number of versions to a somewhat low value. So you should always ask the site owner what the version history policy is in your document library lest you find yourself unpleasantly surprised with the earliest versions of your files missing.

 

Accessing the versions of a file

The three most common ways to access the version history of a file are:

  1. Right-click the file name and click “Version history”.
    This only works in SharePoint Online and SharePoint 2016.
  2. Check the box next to the file name, click the “File” tab in the ribbon, and click “Version history”.
    This works in SharePoint 2013, 2016, and SharePoint Online.
  3. Click the ellipses (…) to the right of the file name, then click the ellipses (…) that appears in the hover pane, then click “Version history”.
    This works in SharePoint 2010, 2013, 2016, and SharePoint Online.
Three Ways to access version history of a file

Three Ways to access version history of a file

The version history pane

Once you follow the steps above, the version history pane will pop up, showing you the current and past versions of your file. You’ll see the information displayed in a tabular format listing 1) version number (in descending order), 2) a linked date and time stamp displaying when the version was created, 3) who made the change, 4) the size of the file at the time the change was made, and 5) any comments made by the editor.

 

Any metadata that is changed will also be indicated in the list. You can sort the columns in alphanumeric order by clicking the column header (e.g., “No.”, “Modified”, “Modified By”, etc.). This is useful if you’re looking for all changes made by a particular person or when the file size stayed roughly the same indicating minimal changes between versions.

 

As an example, see the screenshot below. This is an Excel spreadsheet that has eight versions. They’ve all been created by me and you can see the size changes imply content was added or deleted with these versions. I changed the Title field of the file when I created version 4.0 so the file had a more descriptive name (and will show up higher in search results). SharePoint shows that change with version 4.0.

Version history

Version history

I haven’t made use of the comments field yet. The comments field is useful for providing a short summary of the changes that were made, but it’s easy to forget to include info here because you’re only asked if you’d like to include a comment if you check the file out and then in.

 

Because I rarely use check in/out, I almost never leave comments. But it can be very helpful for you and your colleagues. If you don’t require check in/out in your library, you can still check the file out, edit it, then check it in. You’ll be asked for a comment upon checking the file in.

 

The version pane also gives you the option to delete all versions. If you decide after deleting all versions that you regret that decision, you can restore some or all versions by going to the site’s recycle bin and restoring the versions from there. (More details on restoring deleted versions below.)

 

Taking action on an old version

From the version history pane, you can view, restore, or delete old versions of your files. Click the drop-down menu that appears when you hover over the time stamp of the version you’re interested in.

  • Click the time stamp: This will download the file as it existed when that was the most current version. This gives you the opportunity to open the current version and the downloaded version and compare the two if necessary. Or if you need to get old information/data from an old version, this is how you’d do it.
  • View: This will open the metadata to the file. It does not open the file in a read-only state, even though that’s what you might assume it does. It displays the file name, title, and any other metadata that you might have associated with the document library.
  • Restore: By choosing this option, you are taking that version and making it the “new” current version. The old current version becomes the next-most-recent version. This is useful if you want to completely disregard changes by a colleague, or if the most recent version of the file became corrupted.
  • Delete: Clicking delete will move this version of the file to your site’s recycle bin. This might be useful if there is outdated information that could be detrimental to others’ work if they stumble across that version of the file. It can also be useful if a corrupted version of the file is giving you trouble. Just get rid of it. Note: You can restore a deleted version by accessing your recycle bin, checking the box next to the file name (with version number in parentheses next to it), and clicking “Restore selection”. The version will be restored as the correct version number with accurate metadata retained.
  • Directly link to any version: You can link to a version by right-clicking over the time stamp of the version in question and clicking “copy link address”. When you enter the copied URL in an address bar, it will download the file immediately, as if you had clicked the time stamp, as described in the first bullet of this list.
Version history menu

Version history menu

Buyer beware

 

Version history has its limitations. And you should be aware of what those are. Familiarize yourself with my “Buyer Beware” post on version history. You may find yourself regretful if you don’t.

 

Microsoft resources

 

Note: Version history is very much a valuable aspect of lists and list items, but for the average user, version history in document libraries is significantly more useful and relevant. Version history in lists will be discussed in a future post.

References
icansharepoint. (2016). The absolute basics of version history – icansharepoint. [online] Available at: http://icansharepoint.com/the-absolute-basics-of-version-history/ [Accessed 6 Feb. 2017].

Reproduced under permission from Matt Wade

Share this on...

Rate this Post:

Share: