Le 12 oct. 2011 à 13:21, Christopher Armstrong a écrit : > Hi Quentin > > On 12/10/2011, at 22:04 PM, Quentin Mathé wrote: > >>> 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.
Yes, exactly. We don't have a CORootObject class or similar. Once a core object has become persistent, you cannot change its root object anymore though, because the root object identity (the UUID) is the core object identity and the object identities must remain stable. Also other core objects that refer to it might have their expectations broken, since that could change the core object type. >>> 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. >From what I have understood, the main interest is to support undoing arbitrary >branch operations such as deletion, switch or merge cleanly and in a >transparent way for the user. Is it possible to expand the commit track model to support undo/redo on arbitrary branch operations? It seems to me that if the commit track model was expanded it would be pretty much equivalent to Eric's NestedVersioning. >> 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. ok >>> 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. Your EtoileFoundation doc looks really great. Thanks a lot for taking the time to work on that :-) Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
