Hi all I've committed a new feature to ObjectMerging called "commit tracks". They are the persistent undo/redo history tracks that I've been alluding to at various points in time.
The idea is that we create a new "commit track node" on every new commit. This node has a pointer (forward and backward, like a doubly linked list) to a previous and next node. Each node points to revision on a root object. The "commit track" is just a pointer to a current "commit track node". Therefore, we can undo by moving backwards along a pointer, and redo by moving forward. I still need to write a unit test for non-linear undo/redo, but it should (in principle) work. I also need to add more unit tests for sub-objects to check they are restored correctly when undoing/redoing. I also want to add the feature to just "set" the revision as a commit track node. The side-effects of this is: 1. Objects can have their own revision inside an editing context, but they will only be at one revision at a time. This isn't well enforced, so we'll need to start adding the requisite checks. 2. It officially breaks COHistoryTrack, but that appears to be already somewhat limited in use. It seems reasonably likely to get it working again, if someone can figure out how to let out COEditingContext to support it properly. 3. There is now the concept of a "base revision". This is the revision that a set of changes is made against. Regards Chris -------- Christopher Armstrong [email protected] _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
