Hi Quentin On Tuesday, October 11, 2011 1:45 PM, "Quentin Mathé" <[email protected]> wrote: > > 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
Okay, my original concept and my implementation are a bit different, and both are subtly different to what Eric describes (from what I can understand). I originally intended to treat root objects as a sort of repository of commits (a "commit log" for this argument) against a closed set of objects. You would then have one or more "ommit tracks", which look like Undo Node that Eric describes, which are a tree of revision pointers back to the original commit log and a current "commit track node", which is a pointer to a place in the commit track (where the commit track node in turn points to a revision). In this model, you don't treat the "root object" as an object from the point of view of a user, but a commit track itself. The version I implemented only allows one commit track per object. I wasn't sure how to "let out" the implementation to change the notion of "root object" into "commit log", which is needed to support the above. >From what I understand, Eric wants to implement something similar to what I need in terms of commit logs, but wants to store the "history track" or "commit track" as some sort of versionable metadata? The commit tracks I have are not versionable; you only have a history of the revision pointers. In this way, my commit tracks still allow cheap copies (create a new commit track) and can undo branch switches (you just create a new commit track node that contains the revision of the branch switch - the next undo will go back to a previously selected revision). I'm not sure how to make this clearer, as I find it rather difficult to explain. I'm still learning how to explain it :-) By the way, I updated the manual with a much clearer explanation of commit tracks for newer users (sorry for what I originally had; I knew it wasn't very good, I just needed more time to elaborate on it). It still needs some diagrams, but it should be easier to understand now. > Would a branch creation or branch merge be memorized only the > commitTrackNode table? My commit tracks don't really support branches because you only have one commit track per root object. OTOH, you can easily undo a "revision switch" (which is almost like switching branches, except the revisions are not "named") because a revision switch is stored in the next commit track node. I haven't implemented this, but the implementation should be trivial. > 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? If we let the commit track stuff out so that we can have multiple commit tracks per root object, or separate the idea of commit tracks from root objects (we introduce an explicit "commit log" concept) we could add UUIDs to the commit tracks, and treat them as "root objects" in a sense (this is the logical and semantic complexity I need to get over to evolve the current concepts we have in ObjectMerging). We could then implement branch creation as a new branch. If we also add a UUID to the commit log and the revisions, we could easily share objects over a wire by just pushing revisions back and forth like git. For merging, we will need to have "main base revision" and store metadata for the merged revisions (probably another database column). > For +[COCommitTrack commitTrackForObject:], I suppose the argument can > only be a root object or am I wrong? I select the root object for whatever you pass in. > > 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? Yes, but their last change might still be at a previous revision. They are considered, for all intents purposes, to be at the revision at which they were loaded. Maybe I need to spend some more time working on this stuff to support what Eric's want's to achieve? I was hoping to just push out a version, and expand the fundamentals as a new release (evolve the product instead of dumping everything at once). This gives developer's something to play with, and us more time :-) Regards Chris -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
