Mac OS X Lion file versions, part 1

I’ve been playing around with the new Mac OS X Lion “file versioning” facility. Ars Technica as usual provides an insightful and detailed explanation of this new feature; provides further low-level details (but, see below).

File versioning is, essentially, a consumer-level and user-friendly version control system. Coupled with Lion’s new autosaving functionality, it aims to change and hopefully simplify the way users think about documents. For example, as you type your Pages or TextEdit document, you don’t need to worry about explicitly saving your work: Lion does this for you every once in a while, when you quit the app, or when some other event occurs that requires the system to preserve your work so far. For instance, you can email the document you are working on without first saving it, because Lion does it for you (so what you are sending is exactly what you have written so far). The bottom line is that, ideally, the user should never worry about losing her work. Saving is now a logically distinct operation: it means that the document is currently in a state that the user wants to preserve for possible future reference, even though she may want to continue editing it. Hence, the semantic change in the corresponding entry in the File menu: “Save a version.” If you use a version control system, consider this: “saving” a file just preserves the changes you’ve made, whereas “commiting” a file to a repository makes sure that, should further edits introduce bugs, you can always roll back to working code. In Lion, “saving-as-preserving” happens automatically, whereas “saving-as-committing” requires explicit user intervention, as it should.

Both autosaving and versioning are application-level, not system-level features: that is, they must be supported by each individual applications. This is similar to other Lion features, such as full-screen mode. As you will see, I think this is a very good thing, because—in my opinion—these features do not necessarily make sense for all applications, or in all circumstances. On the other hand, this raises an important question: how do these features interact with traditional file access, be it command-line or Finder-based, or simply via non-versioning apps? If you use Dropbox, this question is relevant: what exactly gets synchronized? Indeed, Dropbox is essentially a fancy front-end to the rsync utility, which I use directly for my work backups (in addition to Dropbox); again, how do versioning and autosaving interact with it?

Autosaving does not present any problems in this respect: once a file is named, further changes are saved just as if the user was a compulsive CMD-S hitter (that is, me). So, rsync and friends work just fine; there are some subtleties related to accessing a file with both a versioning and a non-versioning app, but nothing that interferes with usage: see below for details. The situation for file versioning is a bit more complicated. To investigate possible adverse effects, I had to explore the implementation of this feature. There is some information on the Internet (again, see the aforelinked articles), but a lot of details are missing, and I should warn you that I myself did not go very far—although I did uncover a few interesting tidbits. In case you are wondering, the publicly accessible Apple developer documentation has essentially zero implementation information about file versioning. For all practical purposes, Apple wants you to treat this feature as a black box.

First, the bottom line: file-level access is not hindered in any way by file versioning either. You can continue using Dropbox, rsync, or more generally any non-versioning app, and you will get pretty much the same functionality in Lion as you did in Snow Leopard. This is excellent news. On the other hand, changes made to a file using any non-versioning app will not be versioned by the operating system: again, versioning is an application-level feature, not something that is enforced by the OS. This is probably good, although it does mean that, as far as I can tell, there is no easy way to, for instance, back up versions of a file using rsync (except in a rather inefficient way). Now for the details. This post describes how accessing files with both versioning and non-versioning apps might work from a user, or app perspective; in the next, I turn to some low-level details I was able to uncover, and that I haven’t seen explained elsewhere (but, feel free to provide references if you find them).

Interacting with non-versioning apps: UI considerations

Again, the basic thing to keep in mind is that versioning is application-specific (although possibly, different apps may access the same file and keep a consistent versioning). At the same time, there is no problem accessing files from non-versioning apps. It is best to describe some concrete use cases. The TextEdit (TE) app saves RTF files, which can be opened and edited in any text editor; I used Sublime Text 2 (ST2) as an example.

Here’s a typical, fully-versioned workflow:

  1. Create a file in TE
  2. Add some text, then “save” or “save a version” in TE
  3. Now add more text in TE, and quit without saving
  4. Reopen the file with TE

In this case, the window title shows “Edited” next to the document name. Instead, consider the following:

  1. Create a file in TE
  2. Add some text, then “save” or “save a version” in TE
  3. Quit TE
  4. Now open ST2 and add more text, then save and quit
  5. Reopen the file with TE

The newly added text will show up in TE; however, the window title will not show “Edited” next to the document name. Also, the cursor will be where it was when you quit TE. Importantly, no new versions are created. In other words, versioning must be implemented along the following lines. First, upon quitting in step 3, TE saves the state of the document under consideration: that is, it records that no editing occurred after the last explicit save. Second, the next time you run TE in Step 5, it reloads the document and the configuration file where its status is saved. The latter configuration file indicates that the user did not edit the document after explicitly saving it, so, as far as TE is concerned, the document is exactly as it was when the user quit TE in step 3, even though it is not.

Again, the way to make sense of this behavior is to think that it is the application (i.e., TE), not the OS, that provides the versioning feature. If you modify a file outside TE, clearly TE knows nothing about it: you shouldn’t expect TE to keep track of such changes. On the other hand, there is one downside with this approach. Consider this sequence of events:

  1. Create a file in TE
  2. Add some text, then “save” or “save a version” in TE
  3. Add some more text in TE, so the file is now marked as “Edited”
  4. Quit TE
  5. Now open ST2 and add more text, or delete existing text, then save and quit
  6. Reopen the file with TE

Upon reopening the file in TE, the document will be marked “Edited.” However, the state of the document will of course reflect the edits done in ST2: the document state at the time you quit TE in step 4 will be lost. In the previous scenario, this was not the case, because we did an explicit save before quitting TE; thus, any change we did in ST2 could be undone by rolling back to the previously saved version. However, this option is no longer available to us in the present scenario. Again, this cannot be helped: TE knows nothing of the modifications in step 5, so when it opens the file in step 6, it just knows that some changes were made since the last save—not which changes.

The bottom line is that, if you know you will be editing a file using some non-versioning app, as well as a native, versioning app, it is a good idea to explicitly save before quitting. This is, after all, what you have been doing all along—save your documents before quitting, or sharing. The only difference is that Lion-native apps feature autosaving, and hence don’t force you to save upon quitting: you have to remind yourself to do so.


7 responses to “Mac OS X Lion file versions, part 1

  1. Pingback: Mac OS X Lion file versions, part 2 | Tech, TeX and Theory

  2. I’m kind of glad for some of this behavior.

    I use dropbox a lot for work. Especially to share a file and take turn with coauthors. Sometimes we are both in the same file by accident and one of us can just make sure to close without saving to avoid sync problems. It could be a nightmare if Dropbox were syncing the Edited unsaved versions

    • Hi Ivan, nice to see you here! You make an excellent point-I did not think of this use case. Although, my distorted, overly generalization-prone theorist’s mind thinks that it would be great to use a full-blown version control system when working with coauthors… 🙂

  3. Ivan – I think you have misunderstood. Dropbox and the like _do_ save the ‘Edited’ versions that Lion apps create all the time, including when they quit – they really are saving the changes to disk. ‘Edited’ just means that what’s in the file does not correspond to the most recent thing added to the ‘Versions’ database.

  4. Quote: Sometimes we are both in the same file by accident and one of us can just make sure to close without saving to avoid sync problems. It could be a nightmare if Dropbox were syncing the Edited unsaved versions

    That is the problem. That is exactly what happens.

    The only flaw that Lion has in this model is that autosave in place is the default/norm.

    Imagine a source code control system. You want to commit things to the main trunk when they work, and keep track of the versions along the way, right?

    You fail — completely — with Lion.

    * You have “save a version” — but there’s no guarantee that that version will be around later. Just like Time Machine, after a day old any specific version may be gone.

    * You want auto save (good); you want auto restore (good); you want to avoid the whole “Discard or keep” (which is a major disaster because “review this item” is always the correct choise; good). All this is good. But Lion forces a “commit every change even if you don’t want to save it”.

    The whole distinction of “You are working on a copy until you save it over the old” is gone.

    Lion behaves like the Trs-80 model 100 portable, where there was only the one version of a file. You are not working on a copy until you save, you are working on the original and only copy, but some versions MIGHT be around later when you want to go back.

    No guarantees. Heck, just the opposite — you are guaranteed that the multiple versions will be cleaned up to save space and you have no control over which versions are kept.

    Old 10.5.8 TextEdit had a wonderful feature: Autosave elsewhere. It had the ability to say “Force Quit”, and all your opened, edited documents were saved, and a list of them were tracked; most of your previous editing state was restored when you resumed.

    Adding in state restoration for the stuff that was not saved would have made sense — window position, files opened that were not edited / had been saved, etc. That would have been nice.

    Well, we got that — but we also lost “autosave elsewhere”.

    That’s the problem.

  5. Pingback: À propos de Versions, dans (Mountain) Lion | tiaaft

  6. Pingback: MelaBit | La versione di Apple

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s