Killing revision history to give writers actual version control

Frank Solich won a national championship as head coach of the Nebraska Cornhuskers.

It’s a simple sentence, but it sent me into a panic.

It was wrong, and I’d corrected it several hours before. But there it was, in print, about to be shipped out to roughly 20,000 people. This was back in my newspaper editor days, and I’d covered Frank Solich for more than a year. He is one heck of a college football coach, and he had been part of national championship teams. But he’d never won a national championship as a head coach.

I was furious. There were 10 of us working on the content for this college football preview section and I remembered removing this error made by a freelancer. Seeing it back in his bio, my natural reaction was to search through the files and find out who was to blame.

But my search led me to point the blame at our system. We had all the files on a shared drive. The production team, working on a short deadline, pulled the wrong version from the 31 versions from which they could choose. In their defense, they’d selected the most recently modified one. But that version was modified because the right one was locked for editing and a staff writer opened an older version to cut out content for the web.

No one was being malicious or incompetent. The system just didn’t work.

This problem is one every editor, author and content marketer has dealt with. In every content development process there are many times where one question stops everything: Where is the right version of this content?

Seven years after this football preview section went to print, the continued problem with version control is one of the main reasons we created Beegit.

Current solutions come up short

Today, just about every document or writing solution touts version control. Everybody from Sharepoint to Dropbox considers themselves a player in the content space, but most are just document storage systems that don’t let you write and edit in them. Instead, they track when different versions of a file are uploaded.

This is a real kick in the pants because there is no original version control. You only get what’s added into the system, meaning there is no way to see where a story written from a set of bullet points or a client email went off track. Plus, there are still versions that exist on individual desktops and jump drives that are not accessible in a pinch.

A few others try to solve the problem with a word processor in the cloud. Google Docs is probably the best known, but there are others who promise to save every version of your work. This is better, but it isn’t actual version control. What they offer is a scrolling revision history of one file. This requires endless scrolling through every key stroke you and your contributors have put in the system. When you try to sort through what someone did, you see every change they made to one file. There is no project visibility and there is no way to easily piece together a previous version you’d like to use.

Even worse, to handle all your revisions, some of these services prune your file history without telling you, making a decision on your behalf to lump changes into a version.

Getting it right

With Beegit, we wanted to make version control simple. We wanted everyone involved in a content project to be able to quickly review everything that happened across the entire project. We thought that team members should get visibility regarding who created what and when they did so. We wanted to remove the fear of someone on the team writing over good work by making it easy to restore a past version.

To us, real version control starts with a simple principle: The most current version is what someone sees when they open the online word processor. If someone is working on that, you can see what they’re doing in real time. Older changes are stored and can be quickly reviewed. But they are clearly marked as historical versions, meaning that corrections will never again be pulled from a file incorrectly marked as “Final” or “Edited.”

Real version control also means that you decide when to create a version of your work. Yes, every keystroke is autosaved as you type. But you decide what milestones are worth sharing with other members of your team. We’ve added a change summary for each version you make. This means you can describe what changed from one version to another to communicate with yourself or anyone on your team why content was updated.

If I’d had Beegit in my newspaper days, I would have been able to put a note about the Solich error in the change summary. This would have been another safeguard to make sure people on the editorial and production team knew older versions had a mistake in them.

Creating good content is hard enough work on its own. Isn’t it time you used a next generation word processor that helps your flow and protects your work? Beegit’s beta release is coming later this month to make version control easier. Sign up today and start getting your content under control.

Recent Posts

  • What is Content UX and Why Does it Need to Be in Your...

  • Beegit and Ad-Rank Media

  • Customize your team's content workflow — and fonts!

  • Five quick steps to creating a content plan that kills endless revision loops...

  • Deep content search and improved commenting with resolved comments

  • Updated version control system for easier collaborative editing