When you’re collaborating on documents with other people, sharing a folder on a cloud-based storage system like Dropbox is convenient way to keep everyone’s copies of those docs updated automatically. But nothing in that system prevents two people from opening and changing a given document at the same time. That can lead to version conflicts and confusion.
You could avoid this problem—and make it easier to see who made which changes and when—with a formal version-control system. Teams of programmers working on a project often use tools like Apache Subversion (SVN), Concurrent Versions System ( CVS), or Git to manage their files. These tools ensure that only one person can modify a file at once, let everyone know who’s working on a file at any moment, and keep a historical record of changes so that any earlier version can be recalled in the future.
But for a lot of projects, a complex version-control system and its associated software and repositories are overkill. There is, however, a compromise: Those of us who work on TidBITS’ Take Control ebooks—authors and editors—have over time developed a simple manual system, based on Dropbox, that mimics version control but requires no extra software. Here’s how it works.
Filenames and folders
The first element of our system is the use of two simple folders: Inside any book’s Dropbox folder, we create one folder called Checked Out and another called Old.
We store manuscript files within those folders using a strict naming convention: A manuscript starts with a title such as Book-name-1-jk (where the last two letters are the author’s initials). The next person to work on the manuscript moves that original file into the Old folder, then Option-drags it from there into the Checked Out folder to duplicate it; he or she then renames the new version with an incremented number and his or her own initials: Book-name-2-df, for example. As long as a file is in Checked Out, no one else touches it. After making any desired changes, the editor moves the file out of Checked Out and back into Old. The next person in the editing chain can then repeat the process.
If you’re familiar with Dropbox, you might think that renaming files in this way is redundant. After all, Dropbox maintains its own version history of each file, complete with the name of the user who saved it. But restoring previous copies requires multiple steps on the Dropbox website, and doing so replaces the current version of the file. Keeping our own historical versions makes them easier to work with.
We also rely heavily on the change-tracking and commenting features in our word processor of choice, Nisus Writer Pro ( Nisus Software, $79). (Apple Pages and Microsoft Word have similar tracking features.)
In theory, the author and each editor could just make their changes in a single document (rather than duplicating and renaming it at each step); the change-tracking would then tell us who changed what and when. The problem is that retaining thousands of changes in a document over dozens of writing and editing passes makes it hard to read—the tracked changes, and comments quickly overwhelm the actual text. It’s also tricky to manage those cases in which one person wants to reject a certain change but still let other people see what had been proposed.
So, instead, our routine is for each person working on a document to review the changes made by the previous person, accept or reject them (so they’re no longer tracked), and then make any additional changes with tracking still turned on. That way, except in cases where a proposed change is still under discussion, any version of the document highlights only those changes made in the most recent writing or editing pass.
With those two processes in place, all of our authors and editors can collaborate with minimal friction, be sure their changes never collide, and easily determine when any given change was made. And we can do it all with no special software except the Dropbox client and word processor we all use anyway.