Correctly Deal with Identity Changes and Divergent History #5
Labels
No Label
1
13
2
21
3
34
5
55
8
bug
could have
documentation
duplicate
enhancement
help wanted
must have
question
should have
stale
wont have
L
M
S
XL
bug
bugfix
discussion
documentation
feature
maintenance
postponed
refactoring
wontfix
No Milestone
No Assignees
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…
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.