(Disclosure: I work for Google, but these are my personal views.)
Computers have offered undo for decades. I think I began with apps that offered only one level of undo, and no redo.
Then came apps that offered redo. I remember being impressed by this. The computer could not only rollback my work, but undo the undo itself.
Then apps apps that could undo dozens of changes. I remember being amazed by that. Not only could I replay my work to see what I’d done, I could also go back to any point in time. It was an impressive new capability, like a time machine.
Still, things weren’t perfect. You’d lose your undo history when you close a file. Saving a file then becomes the last chance to review your edits and convince yourself that this is really what you want. If you change your mind, you have to redo all your work manually.
Then came apps like Google Docs, which stored your undo history forever. You can  go back to any  point in time. You no longer need to think about saving files , or make a final decision that a particular version of the document is what you want. Non-destructive editing is also supported in many photo apps like Picasa and iPhoto.
This also applies to services like Google Drive and Dropbox  . They store revision history, allowing you get back an older version of a file , if you accidentally overwrote it, or if it contains information you realised only later that you need.
That’s three different kinds of apps that store revision history — cloud apps like Google Docs, cloud filesystems like Google Drive or Dropbox, and library-based installed apps like iPhoto.
Some photo apps — Lightroom, Google Photos and Apple Photos — take version history to the next level. You can undo or adjust any of the edits, not just the last one. If you crop a photo, then increase the contrast, and then realise you cropped too much, you can reopen the crop tool and adjust the crop. The contrast adjustment remains. With traditional undo, you would have to press Cmd-Z multiple times till you undo the crop, apply a different crop, and then manually reapply all the edits you made afterwards. This is tedious, error-prone work that humans shouldn’t do when computers can do them faster and without making mistakes. Besides, if you forget midway through what the other edits were, you’re screwed. The undo stack was cleared when you applied the crop. Being able to reopen a tool that you applied earlier and adjust its parameters is great .
You should also be able to see revision history for a part of a document, like a section, page or paragraph in a word processor. Or, in a spreadsheet, a particular tab of the spreadsheet, or a column, row, range or cell.
Or you should be able to see changes of a particular type, like only formula changes, or only formatting changes. Or changes involving the tabs in a spreadsheet, namely creating a new one, deleting one, renaming a tab, or reordering tabs.
Or changes made by a specific user in a shared document.
App developers should think about how they offer revision history and undo for specific parts of a document, or specific types of changes, or changes by specific users . It’s time for such powerful undo. Let’s step away from linear undo and redo. It would be freeing to be able to change anything anytime, and with the app categorising your edits for you so that you can easily access and change them later.
 Google Docs has a strange UI — the undo and redo buttons stop working after a while. I just opened a spreadsheet I edited yesterday, and I couldn’t do Cmd-Z or click the undo button in the toolbar to undo the changes. I had to open File > Revision History. In any case, no matter the specific UI you use to access it, the bigger point is that the entire history of the document is available forever.
 Some apps like Simplenote store only a limited number of versions, like 10. In that case, they should keep only the 10 most significant versions — ones that have major changes compared to the previous ones. One algorithm could be: if there are more than 10 revisions, merge the smallest diff with its immediately preceding or succeeding diff (whichever is smaller). Repeat until the number of revisions becomes 10. Alternatively, go by time: instead of keeping 10 snapshots from the past week and nothing before that, spread the 10 snapshots over an year or two.
 Full revision history enables autosave. If you didn’t have full revision history, it would be dangerous to autosave, since the user can’t go back in time if they didn’t like the autosaved version. Not only is your full revision history available, but it’s available on all your devices, since Google Docs documents reside in the cloud.
 Dropbox keeps only one month of revisions if you’re a free user, and one year if you’re a paying user. This is bad. They should keep all revisions as long as you’re within quota. Especially when you’re paying them. If I’m paying for 1TB of storage, I’d like to use that space however I want.
 OneDrive doesn’t keep revision history. This loses out on one of the important safeguards of cloud-based file sync services — if you accidentally overwrite a file, you can get it back.
 Google Drive has an advanced feature, where you can upload a new revision of a file, so that the old and the new file’s revisions appear together in sequence when you open the revision history.
 Lightroom has a UI quirk: it has a history panel that shows you all the edits you’ve made to a photo. You cannot adjust parameters of an edit from there. For example, if one of the edits was a crop, you can’t, say, right-click the history item and select Adjust or Delete. To adjust an edit, you have to remember the parameters of the edit, open the appropriate tool, and reapply the edit manually. For example, if you increased the contrast from 20 to 30, you have to note what the contrast setting was before the edit (20, say), open the contrast tool, and set it to 20. (In particular, you can’t change it to zero, because that will undo an earlier contrast adjustment if there was one.)
Lightroom should fix this. You should be able to right-click any item in the history, and choose Adjust or Delete from the menu.
 What if there’s a conflict? Well, undoing any change should at least be supported in the case of there being no conflict. If there’s one, the app could use the same algorithm it uses to merge changes by multiple users.
Let’s say you made ten edits to a spreadsheet, of which edit 5 consisted of changing the value of cell A1 from 100 to 200. A1 was edited afterward, say in revision 10, and you now try to undo edit 5. The spreadsheet app can handle this by doing what it would do if a user loaded the spreadsheet at revision 5 (after the edit was done), then went offline and undid the change manually, changing the 200 back to 100, and then reconnected to the Internet when the spreadsheet on the server advanced to revision 10. How would it resolve this conflict? It can use the same algorithm to resolve conflicts that arise when you undo a change in the middle of your edit history.