Bug 94438 [Undo] - javadoc - clarify operation remaining in history for undo/redo with INFO/WARNING
The javadoc for the IOperationHistory#undo(...) redo(...) methods is very explicit about the operation remaining in the history on CANCEL and ERROR status, and that it is moved between undo/redo histories when ok. Some minor clarifications: The lack of an explicit statement about INFO and WARNING makes one wonder what happens to the operation. It remains in the history in this case also... Technically, on OK status the operation is not guaranteed to move between the stacks. If it cannot redo after undoing, or cannot undo after redoing, it won't be transferred to the other stack, but in effect will be removed from the history.
bundles/org.eclipse.core.commands/src/org/eclipse/core/commands/operations/IOperationHistory.java
* which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *
 * Contributors:
 *     IBM Corporation - initial API and implementation
 *******************************************************************************/
package org.eclipse.core.commands.operations;
import org.eclipse.core.commands.ExecutionException;
import org.eclipse.core.internal.commands.operations.GlobalUndoContext;
import org.eclipse.core.runtime.IAdaptable;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.IStatus;
/**
 * <p>
 * IOperationHistory tracks a history of operations that can be undone or
 * redone. Operations are added to the history once they have been initially
 * executed. Clients may choose whether to have the operations history perform
 * the initial execution or simply add the operation to the history.
 * </p>
 * <p>
 * Once operations are added to the history, the methods <code>canRedo()</code>
 * and <code>canUndo()</code> are used to determine whether there is an
 * operation available for undo and redo in a given operation context. The
 * context-based protocol implies that there is only one operation that can be
 * undone or redone at a given time in a given context. This is typical of a
 * linear undo model, when only the most recently executed operation is
 * available for undo. When this protocol is used, a linear model is enforced by
 * the history. It is up to clients to determine how to maintain a history that
 * is invalid or stale. For example, when the most recent operation for a
 * context cannot be performed, clients may wish to flush the history for that