Correctly Deal with Identity Changes and Divergent History #5
2 Participants
Total Time Spent: 14 minutes 40 seconds
Due Date
delvh
14 minutes 40 seconds
No due date set.
Dependencies
No dependencies set.
Reference: zdm/undo-redo#5
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "b/divergent-history"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
addChange
returns whether the change was actually added or discarded.@ -16,2 +18,4 @@
private int markedIndex = -1;
/**
* @implNode As this change manager uses a linear history model, all changes behind the last
I can definitely see needing this Javadoc more often.
What about implementing a superclass called
LinearHistoryChangeManager
that automatically supplies the Javadoc and general implementations of functions (undo
,redo
, andaddChange
given a new protected abstract functionremoveDivergentChanges
)?I think we need to create more change manager implementations before deciding what belongs in the superclass and what doesn't. In any case, this branch is probably the wrong place add this.
@ -103,0 +124,4 @@
manager.addChange(change);
manager.undo();
assertTrue(manager.addChange(new IntChange(wrapper, 2)));
assertFalse(manager.isRedoAvailable());
Perhaps you should
a) test by adding two changes that are undone
b) Add an assertSame for the size of changes stored
Good point. I actually discovered a bug through this. The fix is coming in the next commit.