Le 28 oct. 2011 à 15:09, Christopher Armstrong a écrit : > Hi Quentin > > On 28/10/2011, at 20:03 PM, Quentin Mathé wrote: > >>> One of the things I want to avoid is "hierarchies" of root objects, which >>> may exist with nested versioning and make the whole thing really >>> complicated. I think trying to keep the object model as flat as possible is >>> important to keeping it usable. >> >> I agree. Keeping the object model as flat as possible is important, since we >> have we'll also have COGroup to organize core objects but in a way that >> doesn't create hiearchies or nesting, although at the UI level it might >> appear to do so. I'm giving this example to outline the fact we should try >> to mimize the organization or nesting models we use to keep things obvious >> at the user level. >> >> This puts aside, I think Nested Versioning doesn't necessarily imply the >> nesting of the root objects, I'd envision it more as a possible branching >> policy valid inside a compound document. > > I had the same thoughts. A "inner document" is really just a link to another > root object a specific revision. It doesn't imply it is "stored inside", it > is just referenced inside.
Exactly. That's what I was trying to express but less clearly :-) >>>> For ObjectMerging, we could use a special ref marker rather than a plain >>>> UUID to represent references between root objects. >>>> >>>> A ref marker could include an optional branch UUID. Since a branch has a >>>> head, the ref marker would implicitly point to a specific root object >>>> version. If there is no optional branch UUID, the (inner document) current >>>> branch is picked. With this model, we could also automatically branch >>>> inner documents in a way similar to what you suggest above… >>>> For example, on branching the outer document, all the inner documents are >>>> branched. These "nested" branches would be private, in the sense they >>>> wouldn't be listed at the UI level among the branches of each root object >>>> (well, unless you request it). We could eventually use the outer document >>>> UUID as the inner document branch UUID, not sure it's a good idea though. >>>> >>>> Rather than serializing a custom reference object, we could still use a >>>> plain UUID by generating a new UUID that represents a core object UUID + >>>> branch UUID pair, and a database table to store the mapping. I'm not sure >>>> it's a good idea either, because it would make the debugging less easy and >>>> much harder to interpret core objects exported as plists. >>> >>> I don't think its a big conceptual burden for debugging, but yes, it does >>> make things more difficult. >>> >>> The main problem I forsee is the need for COEditingContext to allow >>> multiple copies of the same object in the same context *at different >>> revisions* at the same time. It doesn't seem entirely unreasonable to want >>> a copy of the same object in the same document but at different revisions. >> >> I gave some more thoughts about this problem. My current conclusion is we >> should merge notions such branches and root objects at the storage level >> (more or less your commit log idea I think). I mean that a branch creation >> would result in a new core object (that implies a new UUID). In this model, >> creating a new branch, copy or root object is the same. >> >> We would have a main HistoryUnits (or HistorySequences or a better name) >> table that lists both branch and root object UUIDs, then a table >> HistoryRelations to memorize how public and private branches and copies are >> related to root objects. There might be some ways to improve this model, but >> at least this gives a basic idea and it seems very close to commit tracks to >> me. >> >> For COEditingContext without making the current implementation more complex, >> we can then easily have the "same" root objects at various revisions at the >> same time, new entries in HistoryUnits and HistoryRelations table would make >> possible to support that. >> A public branch would be a branch exposed to the user and a private branch >> would be an object accessed as a particular revision (but without a branch >> from the user viewpoint). >> A branch public or private, a root object and root object copy would all >> correspond to the same 'history unit' construct at the store level. >> >> What do you think? > > This is originally what I wanted to use commit tracks for, but I wasn't > exactly sure how to convert them into this sort of structure. > > I presume that you mean a "new core object" is just a placeholder reference > with a new UUID - the internal objects still maintain the same UUID between > different copies. By "new core object", I should have written "new root object" to be precise. Not sure what you mean by the internal objects? > For this, would we just add a UUID to the commit track and call it the "root > object"? Yes. > I was looking into making commit tracks have their own UUID for this, but I > wasn't sure if that is equivalent to what you describe above. I think it is equivalent. I was envisioning two tables with the columns listed below: CommitTracks (was called HistoryUnits) - UUID - CurrentNode CommitTrackAncestry (was called HistoryRelation in my mail) - UUID (the commit track UUID) - ParentUUID - ParentNode (a commit track node id) - Branched (boolean) - Public (boolean) For a normal branch, we have: - a valid Parent (UUID + Node) - Branched = true - Public = true. For a private branch (such as a inner branch a la Nested Versioning), we have: - a valid Parent - Branched = true - Public = false For a new root object (from scratch), we have: - no Parent - Branched = false - Public = true (doesn't really matter in fact) For a root object copy, we have: - a valid Parent - Branched = false - Public = true (doesn't really matter in fact) For a root object linked as a precise revision, it is the same than a private branch: - a valid Parent - Branched = true - Public = false. We surely need some extra rules such as: - you cannot branch a commit track if branched is true We probably need an extra table to store infos related to Branches such as their names etc. We might want to move the Public column to this table, or introduce a UUID-based owner notion (e.g. an outer document owning a inner document branch). CommitTrackAncestry is not named CommitTrackGraph because to build the entire history graph we would need another table that describes the merge points. The current limitation I see with this model is that you cannot support live links that automatically reflect their root object current branch. It's surely possible to remove this limitation, but to propagate branch switches to the related live links doesn't seem like a good idea (too hard to predict for the user). Let me know if this is close to what you had in mind, and if you see any holes in my reasoning… Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
