In a sovereign desktop app with multi-level undo/redo (ie Photoshop, Word, etc), would being able to save and restore the undo history of a file with the file itself be a good thing or a bad thing? My initial reaction is "good", however I've found I occasionally hold Control+Z until it stops working to revert to a previous version. Any studies or experience with this?


7 Answers 7


One example of such an application is IntelliJ IDEA (and some other programming environments). In addition to the usual project-specific external revision control, IDEA has a user-specific local history which saves a revision of every file on every save (the history is stored inside the user's home directory). The old revisions are stored by default for 3 active work days, after which the old revisions are removed. Coupled with the feature of automatically saving all files every few seconds (my preference is after being idle for 5 seconds), this means that you will never need to think about saving files, and you can always get back the old data. It's a real lifesaver when programming. (Sometimes I also use it to find out how many hours I've worked on a project, to record my work hours, because the local history shows the date and time of every change.)

An external revision control is still needed, but for other needs - there you will commit changes typically when you get some consistent piece of work done, at least once every 1-2 hours, and it's also a way to distribute your changes to other team members and to make backups. The local history on the other hand is for recovering from mishaps a few seconds or minutes after it happened.

I think that many other programs would benefit from a similar local history. I would love it if my Office Suite would have it, because a undo/redo stack and manually saving the files are very primitive ways of recovering lost data (they don't allow selective recovery and they don't survive restarting the program). I also remember seeing an image editing application (I don't remember the name - I think it was only for Mac), where all edits were done as transformations of the original picture, and you could at any time go back to change any of the previous edits. So such an history is possible even with image editing.

I don't think that I would want the history to be stored inside the file being edited - otherwise it would get very big (a revision every couple of seconds; my local history for programming projects I've worked on within one year is 370 MB) and it could cause a security problem by leaking data which you thought you removed - but a per-user history would be great.

  • Good idea on making it per-user. Should it be presented as a separate feature or just made part of the existing control+Z? Commented Aug 11, 2010 at 23:17
  • Yes, I really love this feature in IntelliJ IDEA. And I think a lot of application would benefit from similar features. Lot of web-application provide similar functionality. For example the google-docs. (ok it doesn't store it so often)
    – Gamlor
    Commented Aug 11, 2010 at 23:20
  • @Robert Local history would need to be its own feature, because it requires its own UI for recovering old revisions (see the demo at jetbrains.com/idea/training/demos/local_history.html). But it's good to have also Ctrl+Z at the same time, because Ctrl+Z can be more convenient for undoing small typos. Pressing Ctrl+Z modifies the document, so it should add a new revision to local history. Commented Aug 12, 2010 at 8:30
  • Picasa, from Google, is a photo editing application that behaves as you describe - all your edits are stored as changes to the original file. You can go back and undo changes at any time.
    – Bevan
    Commented Jan 12, 2011 at 22:53
  • I so wish Notepad++ did this. It keeps all your last open items like many IDEs but on occasion I'll forget my undo history has been lost because I close the window/ect
    – Zelda
    Commented Oct 15, 2011 at 16:02

every once in a while I wish photoshop or word had such functionality, On the other hand like you said I often press control-z until it stops.

Another issue is performance. Think a draft word document being passed around and edited for weeks. It would be huge! and take forever to load.

Yet another issue is privacy. I don't want people to see what steps I took to paint the picture in Photoshop, or what my previous proposal to the board was.

In conclusion, I think it can be nice but you would have to have a way to purge the history for performance sake and for privacy and also perhaps if a person presses ctrl-z you should stop when you hit the state the doc was when it was last opened and ask if he is sure he wants to continue.

  • Good idea on the purge feature (though would it be too complex?). Hard drive space is cheap these days, though. Commented Aug 11, 2010 at 23:16
  • HD space is cheap but try to email a 700mb file. Also think how long it would take to load the full stack, even with paging it would be way to slow.
    – Sruly
    Commented Aug 11, 2010 at 23:26
  • 1
    I think you are right. but you know, the idea can be somehow changed! lets don't store history with the file itself. we can have some solution like Version Controls built in the application. Keep track of history in a different file. Commented Aug 12, 2010 at 8:14
  • @morteza Good idea in general but it would be trouble to have to move 2 files together all the time, although this can be fixed by zipping them into one file making it transparent to the user.
    – Sruly
    Commented Aug 12, 2010 at 9:02
  • Yes, zipping them together makes it easy to move them. but you know, it has the security risk you mentioned before. so a program can use something like database. one can have a database for history of files. so nothing needs to be changed by moving files except a field in the database (also this solution works for moving file in a computer). Commented Aug 12, 2010 at 19:59

It seems to me that you don't want undo/redo, but file versioning, or revision control. (I don't know about Photoshop, but Word has this feature, disabled by default).

  • Yes, this might make a good feature but the question still stands. Commented Aug 11, 2010 at 23:14

Perhaps a timeout on undo that defaults to 5 minutes (and may or may not be an editable timeout length)? It would address the very valid concerns that people have here about the value of undo data days/weeks/months later. And it would address the issue brought up here of accidentally closing an application and losing the undo data. And would maintain the value of holding down Ctrl+Z to clear out all changes during the "session" (where now a "session" means any usage that has inactivity less than 5 minutes at a time)


Personally I think it is bad. A Version control system would be better for this. I don't think users expect undo to work this way. I don't see how they can remember what is in their undo stack back several days. And potentially this can eat up a lot of disk space and memory in your app. I mean users essentially never get rid of data. How do you deal with use cases where users want to free space on their hard disk because they are running low?

  • Hmmm... a couple good points. Re: disk space, though, I don't really get that argument. A "clear undo history" is easy enough, and 30-50K (max; probably less) per document isn't hard to find Commented Aug 20, 2010 at 18:55

I like this a lot, for small and larger projects.

Google Chrome when you restore a tab you accidentally closed, will come with full back history - which is awesome in its own right.

Some productive applications build their artifacts from a stack of actions, like 3D modelling where you apply operations in an endless stack and can then go in and change earlier operations and have that change propagate through the stack to the current modifier. The file format is then based upon the flow of actions, not on an end result.

Any application where it's not obvious to "publish" a final or public version of an artifact however would incur a lot of risk. Like if you send a word document with complete history of changes that would offend the receiver (like an offer where you've changed the client name from another client or whatnot).


My feeling is that this is the wrong tool for the job. Undo and Redo is about the actions within this process, so that I can undo/redo an action before I save and move on. Saving across sessions seems to me to be a different requirement, versioning is more the style. I can see there is a place for keeping the redo stack with a saved version of a file/application, meaning that you could open a version and immediately undo the previous actions, but when you start do more actions, you lose this - the stack is restarted.

I can see that it would be useful - I can see some times that I would like it - but I still think that it is not the right useage of this facility.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.