Hi Christopher, Le 5 oct. 2011 à 14:06, Christopher Armstrong a écrit :
> 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. ok, I understand the basic concept. This looks identical to what is described in the NestedVersioningDiagram.pdf available on Eric's github, right? Is there any difference? Note: the diagram is available at https://github.com/ericwa/NestedVersioning/tree/master/Docs Would a branch creation or branch merge be memorized only the commitTrackNode table? If I have a root object Y and I branch it, I get a new root object X (probably a cheap copy) and the commit track might look like that: - Branch 1 committracknodeid, 3 objectuuid, Y prevnode 2 committracknodeid, 4 objectuuid, Y prevnode 3 - Branch 2 forked from 1 committracknodeid, 9 objectuuid, X prevnode 3 Or do you have another idea in mind to represent branching? For merging a branch, given there is a single previous node, how would you represent or access the parent nodes from the revision that represents the merge? For +[COCommitTrack commitTrackForObject:], I suppose the argument can only be a root object or am I wrong? > 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. Do you mean all inner or sub objects, that belong to a root object, will have to be at a revision or state that matches their root object revision? > 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. ok Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
