Version control without the hassle
Most projects require collaboration, and collaboration requires coordination: We need to know: who made what changes when? We need tools to aggregate work performed individually into a coherent whole, and we need mechanisms to roll back any edits that did not prove useful.
In software development, all of this is handled by dedicated version control software such as Git, Mercurial, or Subversion, often together with online services such as GitHub. These are essential tools to most any developer and we simply could not live without them.
But not everybody uses such tools, and even hackers who live and breathe Git do not necessarily place all of their files under version control. Why not? Because setting up a dedicated version control system takes some modest amount of skill (minimal to most hackers, but substantial to most others), and using Git or Subversion in your daily work requires a little bit of extra effort. Good luck trying to explain to your grandparents how (and why) to do a Git commit or merge!
Hence, collaboration and coordination for most users these days centers around file sync-and-share services such as Dropbox, Google Drive, Box, Microsoft OneDrive, or Apple’s iCloud, combined with emails explaining what changes were made and what remains to be done. Clearly this is an improvement over sending version after version of edited documents back and forth as email attachments, but it is nowhere near the elegance of a dedicated system like Git.
The natural question is: Is it possible to combine the ease of file sync (i.e. “all you need to do is edit the file and hit save”) with an easy-to-use complete change-log, and a simple yet smart mechanism to undo any desired set of changes?
Of course it is.
In fact, to some extent, this is already a reality. Most cloud productivity and file sync services already store (some form of) the edit history of your documents. Most of these services can show you a simple list of recently edited documents and let you restore an old version of a file if needed. Storage cost per gigabyte is dropping steadily toward zero, and for all but the largest files there really is no good reason anymore for such services not to store all versions of all your files.
The main unsolved challenge is designing an effective user interface. If every single save is “committed” (in the sense of a Git commit) without any intelligent commit message, how can anyone make sense of the resulting endless sequence of edits? How can one easily visualize exactly what edits have been made, when, and by whom, for all kinds of files (not just plain-text files)? How should the interface handle conflicting edits? How can the interface support undo for a single file or across multiple files? These are very real user interface issues that need to be addressed. Could one make an interface that is simple enough for non-technical users, yet sufficiently powerful that it provides real value and functionality? Something that just works without requiring hours of training.
In my opinion, none of the existing players provide us with adequate tools (yet), but I do believe an effective interface could be designed. In this post, I give some suggestions for features that in my opinion need to be part of an eventual solution. Some of these features I have already implemented in an existing Mac app called Revisions for Dropbox, which provides a complete change-log, easy diffs of edits, and folder-level restores for the popular Dropbox service. As a result of Dropbox automatically storing old versions of all your files, all of the above features are even available retroactively. You are thus invited to test these features in practice on the recent history of your very own files!
There are still a lot of ways in which Revisions could be improved. Below I detail the four features that I believe are key to an effective interface, and I describe the extent to which Revisions implements them.
1. Grouping related edits
Chances are you’ll save several intermediate versions of your work while you’re editing a document. You may also be working on multiple related documents simultaneously. Together, this amounts to a lot of minor edits that, when you’re done (hopefully) amounts to a coherent whole. Whoever is looking at the resulting change log is usually not interested in all the intermediate details but rather is interested only in the end result: exactly what was changed as a result of this particular session. Thus, in one way or another, related edits need to be grouped together and represented as a whole (combined) edit.
As a concrete example, Google does something like this when leaving unchecked the “Show more detailed revisions” option in the revisions view of Google Docs, but aside from this switch the user is given practically no control over how revisions are grouped. Dropbox does not group revisions at all.
In Revisions for Dropbox, any edits that are performed in close chronological proximity are grouped together, and the threshold (set at 10 minutes by default) is easily adjusted by the user. Furthermore, users can fine-tune the resulting grouping manually. This allows the user to define precisely the time-span and granularity to look at.
This is, however, only a starting point. A much-needed improvement would be to allow users to group edits which are not chronologically sequential. In addition, one ought to use a hierarchical scheme that could distinguish between high-level groupings (such as all work done during a single day) and low-level groups (perhaps individual tasks on a to-do list).
2. Annotations
A critical part of effectively using a dedicated version control system is writing clear yet informative commit messages. These are human-written and human-readable descriptions that explain any given edit.
Similarly, there is a definite need for “commit messages” for edits in your Dropbox, on Google Drive, or wherever. Without these, how else would you communicate to your collaborators (or your future self) what changes were done, and why, without reverting to email? In my humble opinion, there are two crucially important aspects to them.
- They should be optional. (You don’t want a pop-up dialog every time you save a file in Photoshop or Powerpoint.)
- It should be possible to add them after-the-fact. Basically, you should be able to view your (unannotated) change-log at the end of an editing session and, at this point, group edits logically together and add an annotation to each group.
Revisions does not yet include any mechanism to add such commit messages. It should, and I hope to add this feature in the near future.
3. Intelligent, beautiful diffs, for all kinds of files
What is the first question you ask when you come back to the chess table after getting yourself a drink? Strong players of course need not ask anything, but for everybody else, it probably is: “What move did you just make?” To stay on top of what is happening in a game, or in any collaborative project, you need to be able to compare the state of something right now with the state it was in last time you checked. This obviously applies to all your files.
Most software development revolves around editing text files. One of the main advantages of this is that there exist excellent tools to diff changes (i.e. compare two files and see exactly in what way they differ) and merge edits (i.e. combine the edits inherent in two different versions of a given document).
Outside software development, however, text files are nowhere near as prominent. Yet to really see what changes other users (or you yourself) have made, diffs are needed. Do we have the tools necessary to properly diff Microsoft Word or pdf documents, or images in png or jpg format, or slideshows such as Powerpoint or Keynote files? Unfortunately, in most cases, the answer is no. Even fewer tools exist to merge such documents.
But all hope is not lost. For example, there is a wonderful graphical diff client for Mac called Kaleidoscope, which can handle a number of image formats in addition to text files (it is a bit pricey but at least there is a free trial). Other tools exist as well, though sadly most are fairly niche products.
Revisions does not even attempt to solve this difficult problem on its own. Instead, it simply connects with existing diff apps to allow the user to view a diff of the edits to any file in your Dropbox (combined over an arbitrary number of intermediate edits inside a group) that the connected diff app can handle.
In the long run, I’d love to see developers of productivity software include native diff and merge capability into their apps. After all, who else would be better placed to create a beautiful, effective diff engine for a given file type than the developer of the app that introduced that particular file type.
4. Easy, intelligent undo
How often do you use the “undo” feature when you’re writing a document or working on a design? If you’re like most users, you use it fairly heavily. Having the ability to undo makes it risk-free to experiment, and of course makes it much faster to backtrack if you do make a mistake.
Similarly, we need undo for the entire filesystem. Of course, this exists in various forms, but the interface is typically not inviting. Dropbox, for instance, lets you restore previous versions of files, but only one file at a time. Most other cloud service providers work similarly.
At the very minimum, in my opinion, users ought to have the power to easily revert actions that potentially affect multiple files simultaneously. Revisions lets users undo all changes in a single edit group with the click of a button. In addition, there is the option to restore a given folder (including any subfolders it contains) to its exact state at a user-specified point in time.
The holy grail of undo would be the ability to undo some earlier change to a file, without simultaneously undoing any later edits made to that file. In fact, this is really just a merge operation, so for file types for which merge operations can be supported this is definitely possible. I’d like to see this operation more widely supported.
Ok, so where do we go from here?
Please add your comments! Can we take some of the main features of version control software such as Git and provide them to users of Dropbox, Google Drive, or OneDrive with an interface that most anybody can use? What are the must-have features that need to be implemented?
(Fortunately, we do not need to wait for the service providers to implement such features, as all major platforms come with decent APIs that we can use in our work. For example, my app Revisions for Dropbox simply uses the Dropbox Core API).
Or should we just stick to using Git for all our important files and forget about any form of version control for everything else?
