I know of three approaches to UnDo. Depending on your application, one of these may be better suited than the others.

• Each time the user makes a change, save a backup copy of the work-in-progress before making the change. In a graphics program, you might save a copy of the image prior to the change in contrast, prior to the blurring, prior to the image rotation. These backups are large and memory-expensive, so you would only keep a small number, say the last three. Most of the time, the important aspect is to be able to undo the last step, thus encouraging exp[erimentation. On the plus side, undo is a trivial operation, simply swap the displayed image and the backup image, and enable the ReDo button.
• Keep a list of the operations performed. This is a natural for object-oriented graphics. To drop a change, drop the last item on the list. If an object is moved, you have a choice between creating it in its original location and then moving it, or modifying the original creation point, but appending at the end of the performance list an invisible entry with the information needed to revert to the original location. The list is gentler on your memory usage than keeping entire images, but in typical memory/cpu trade-off, it can sometimes require a lot of proceessing to generate the final image.
• Solution two is not suitable for a word processor storing War and Peace. Instead, keep a list of nodes which specify how to UnDo/ReDo. This works well for a word processor, where it is possible to undo both insert 'Praise the Lord!' at position 65535 and delete 'Praise the Lord!' from position 65535, but not for a graphics program, where there is not an inverse operation for blurring. Generally, this approach is good for an undo list longer than supported than Solution one, yet shorter than Solution two. You might implement a list of a dozen or a hundred entries, or back to the most recent Save.