From MozillaWiki
< Labs‎ | Bespin‎ | DesignDocs
Jump to: navigation, search

Viewing the Past

Bespin should have a number of mechanisms that look into the past:

  • Local undo (i.e. ctrl+z to remove changes made at your keyboard)
  • Undo stack on server (i.e. also contains changes made by others)
  • Save history (called 'local history' by Eclipse)
  • VCS


Local Undo

When the user presses ctrl+z they generally expect their last change to be undone, and do not expect others collaborators changes to be undone (especially since changes made by other collaborators may be in another part of the document) also you would not expect your changes to be undone by another collaborator.

If one user has 2 windows open at the same file on the same computer at the same time, it is less clear what they would expect. It is my opinion that it is useful if the user can concentrate on 2 different tasks with separate undo queues, and this is much simpler to implement than attempting to merge 2 undo queues on the server.

In various editors, different actions cause the undo queue to be flushed:

  • save
  • closing the file and re-opening it

I propose that local undo queues are not persisted to the server. This will give us a consistent metaphor with collaborating between yourself and other users.

There is concern that another collaborator might make a change to your file that you are unable to undo. We handle this using the server undo history...

Server Undo and Save History

The local undo stack only records the changes made in the current window. The server merges changes made by all collaborators on a document and records the 'official' history of a file.

The server records a history of changes made since the file left version control to allow users to browse through the server undo stack, through the save history and through version control in one set of actions.

The server can easily look at the [tip|trunk|head] from VCS (head from now), and previous versions. The server also stores:

  • The current saved version of the file (if its hash has changed or there are other saved versions)
  • A set of diffs to go from head to the current saved version, one per save action
  • The current 'live' version (i.e. includes unsaved changes)
  • A set of diffs (from mobwrite?) to go from the current saved version to the live version

The user should be able to view any version, compare any 2 versions, or replace the current buffer with any version from the past.

User Interface

Mockup of what the user interface might look like

The user interface to the time machine/carbonite feature is expected to be split into 2 parts - the top section showing changes between 2 versions, the bottom section showing a scrolling view of recent changes that includes diffs to last saved, saves to TIP, and VCS changes.

This UI will become visible either on some command, or on a keypress. It is expected that the default comparison will be between the current file state and the latest from VCS.

It is likely that we will not show diffs in 'Word' style as shown in the image, but instead highlight the current source with background colors to denote changes, and a hover mechanism to reveal the older version.