Le 12 oct. 2011 à 00:49, Christopher Armstrong a écrit : > 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).
ok > 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. Not sure what you mean by 'from the point of view of a user'… From the end-user perspective, a root object is the same than a core object e.g. a photo, a contact, a composite document etc. So it looks to me the notion still exist from the user perspective. Especially if you consider the inner vs root objects distinction, and what this implies when moving inner objects between root objects. I understand that in this model, a root object doesn't exist without its commit tracks and each state (or point in time in a branch) is bound to a commit track. However a root object UUID still seems needed to know which are the commit tracks that makes up the root object (and also insulates this root object history from other root objects). From this perspective, there is still a root object notion even at the store (or history model) level. What am I missing? > 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. I suppose to make the commit tracks versionable would mean to use commit tracks to describe the store history (repository-like actions such as merge, branch, root object creation etc.). These store commit tracks would point to root object commit tracks rather than revisions directly I think. > 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 :-) I understand the details much better now. However it's hard to describe it clearly to someone without some diagrams. > 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. Yes, great explanation it's much easier to understand :-) >> 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. ok >> 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 branches are identified by UUIDs (as we discussed it with Eric), then a branch is just a commit track or a subcase, right? Each revision could have a commit track or branch UUID attached to it, then this implicitly creates a history graph per root object. > 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. Yes. > For merging, we will need to have "main base revision" and store > metadata for the merged revisions (probably another database column). ok >> 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. ok I wasn't sure about that. >>> 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. Makes sense. > 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 :-) ObjectMerging starts to look good enough to play with it. It looks like a good idea to release a preview version in the next months. I think we can switch to a better history model later while keeping untouched the core concepts (root objects, editing context, store etc.) and the core API such as COEditingContext, COObject. Eric, what do you think about this approach? At first sight, NestedVersioning looks like an incremental evolution over ObjectMerging rather than a redesign from scratch. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
