Hi Quentin On 12/10/2011, at 22:04 PM, Quentin Mathé wrote:
>> 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? Nothing I believe. This seems to be a good interpretation of what I was missing. As you probably noticed, I expanded on my ideas as my email continued, which means I'm still thinking some of this stuff out. What you say about root objects still being needed is correct. I was (rather awkwardly) trying to describe how commit tracks are currently bound conceptually to the notion of a root object, because in our design, the root object is what separates sets of objects from each other. What I realise now, and which I didn't when I wrote my last email, that is if we call that set of objects and the revisions applied to it a commit log, then the notion of root object is merely arbitrary, i.e. it doesn't matter which object in that set is "root". All that matters is that the group of objects are in fact separate from other groups of objects. So yes, you are right in that a root object is intimately bound against the idea of a commit track in this model, because when you load it, you need to know which track you are loading it against (to work out what revision to load based on the current state of that commit track). >> 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. Ah ok, I didn't gather he wanted to describe a history of whole repository operations. I'm not sure I see the need for this, but nonetheless, it explains the complexity of it. > If branches are identified by UUIDs (as we discussed it with Eric), then a > branch is just a commit track or a subcase, right? Yes exactly. > Each revision could have a commit track or branch UUID attached to it, then > this implicitly creates a history graph per root object. Well actually, its the other way round - the commit track node points to a revision. The revision itself could be referenced from any node in any commit track. >> 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. > Sounds good. I was hoping for a release sooner rather than later, but I guess some time to document EtoileFoundation and wouldn't hurt. Cheers Chris -------- Christopher Armstrong [email protected] _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
