As noted in my previous post, NSPersistentDocument implements reversion by calling -reset on the managed object context. I was playing with this for Sandvox, and ran into somewhat of a problem with it, which may be an unusual edge case; I'm not sure!
We're using the binary store, and also implementing old-style autosave — whereby a copy of the document is periodically saved in case the computer dies or Sandvox crashes.
If you attempt to revert the document after it's been autosaved, the file on disk does indeed go back to the correct reversion (in fact it's not touched at all). But the context only reverts back as far as the autosaved state. What's happening here?
It seems that, at least for atomic stores, -[NSManagedObjectContext reset] only resets the state of the context. It doesn't reread the data from disk, instead relying on its own existing, cached copy of the data.
Fortunately I was able to figure out a workaround; rather than reset the context, do something like this:
The trick, basically, is to replace the existing store with a new one, thus triggering a refresh of Core Data's cache.
A major downside of doing this mind, is that the context will be temporarily unusable while there is no store attached, so make sure all controllers etc. depending on the context are able to handle this, or torn down (as NSPersistentDocument does)