On 30 May 2005, at 15:17, Jesse Ross wrote:
Because we assume that documents are always saved, if we want to create and track different versions of a document, we press the Save Checkpoint menu item and the document at that point in time is explicitly recorded. This is really only important in memory- lacking systems. On a system with a lot of memory, all points from the beginning of a document's life to the end is saved -- on memory- lacking systems, the most recent version of a document is preserved, as well as all checkpoints, while stages in between may be dropped as memory gets reduced.
I saw the Checkpoint option as more a user-thing than a system- thing. Checkpoints would simply be a named state in a document's undo history. They would be indexed, and people could easily jump to them. Examples:
In a coding project, I might checkpoint every time I make a release, with the release name. I might also checkpoint every time I fix a bug, with the name of the fixed bug.
In a collaborative document, I might checkpoint every time I hand over to someone else to edit, so I can replay their changes one at a time (jump to checkpoint, then redo repeatedly). I might also checkpoint when I make a major change.
Many people I know do a sort of manual version control thing - they periodically save copies of their document under different names (e.g. `letter - second draft.rtf'). Checkpoints are there to facilitate this kind of thing - they are just markers you can easily jump to.
From an autonomic computing angle (something close to my research area) they are also useful, because they provide additional knowledge to the system and can be used to determine which parts of the undo history can be safely compressed, and which it can't.
Note also that when you say memory, you are talking about virtual memory - or the analogue in a higher-level form (i.e. serialised objects, rather than serialised memory blocks).
