Le 20 oct. 2011 à 22:01, Eric Wasylishen a écrit : > On 2011-10-20, at 3:46 AM, Quentin Mathé wrote: > >> Le 19 oct. 2011 à 23:23, Eric Wasylishen a écrit : >> > Thinking about this a bit more, the problem is that there are many > definitions of "copy". > > For an embedded object, I can think of two > - return an independent copy of the embedded object, with no relabelling > - return an independent copy of the embedded object, with relabelling every > object to a new uuid and updating any references inside the copy which refer > to old uuids to new uuids. > > For a persistent root, I can think of a lot more: > - "copy history graph": return an independent copy of the entire history > graph (like doing "cp -r some_git_repository new_copy". This is what I was > thinking of doing in nested versioning -upon ever commit, all nested > persistent roots inside an outer persistent root would be copied in this way.) > - "create branch": create a new branch off of the current state of the > persistent root, and return a link which tracks the latest version of the > persistent root on the new branch (interestingly, this is the only one that > performs a _mutable_ change to the persistent root) > - "non-versioned copy": return a non-versioned (embedded object) copy of the > current version of the persistent root, without any relabelling. > - "non-versioned relabelled copy": return a non-versioned (embedded object) > copy of the current version of the persistent root, with relabelling every > object to a new uuid and updating any references inside the copy which refer > to old uuids to new uuids. > - "link": (not really copying) return a link to the persistent root which > will continue to track further changes (i.e., just the persistent root's > uuid) > - "link to version": (not really copying) return a link to the current > version of the persistent root which will not track further changes (i.e. a > string "uuid:version") > - "new persistent root": create a new persistent root with an empty history > graph, and insert as its contents the "non-versioned relabelled copy"
Does "non-versioned copy" implies that the copy has a new UUID? "non-versioned copy" is a like a shallow copy while "non-versioned relabelled copy" is like a deep copy? I'm not sure a "non-versioned copy" is really possible in the current ObjectMerging model. I mean if you don't relabel the embedded objects, the embedded object UUIDs are reused accross multiple root objects (which we disallow iirc) or you start to track embedded objects by UUID+revision rather than just by UUID. For "non-versioned relabelled copy", I suppose the relabelling only applies to the embedded objects and doesn't concern linked root objects? "copy history graph" could be called "versioned relabelled copy", right? "versioned copy" isn't supported because each root object is like a sandbox (embedded objects cannot be shared)? For "link", if a root object current branch is changed, this changes how this root object appears everywhere it is linked, right? As a side note, I would rename "create branch" to "link to branch". > Can you think of any others? If we start to consider if links are traversed or not on copy, this should create some new categories. We shouldn't worry about it though :-) I don't think we will ever want to traverse links on copy. See also my previous reply to Christopher where I advocate to treat branches, root objects and copies as the same construct. This would reduce the variations you propose to two (from a technical viewpoint): - new history unit (with an optional parent for a branch or copy) - non-versioned relabelled copy "non-versioned copy" isn't possible since object references are based on simple UUID makers as we do currently. You can create a "non-versioned relabelled copy" that looks the same than a "non-versioned copy", so it isn't an issue (unless I overlook or misunderstood some point). > So, in your examples, you would use the "link" rule for putting photos in the > page layout document, and the "create branch" rule for the photo montage. > >> 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. > > Hm, interesting. This would basically simulate the nested object being > "inside" the outer object, except that the inner object would share its > history graph with other users of the inner object. > > If we go down this route we need to refine the concept of "current branch" > and "current version". > > In the ObjectMerging model every persistent root has a "current version" > which also defines the current branch. It's the main mutable state of a > persistent root, and is valid globally. > > In nested versioning it is the same, except for a nested persistent root, the > current version is only valid inside the parent persistent root, so you can > make a commit that changes the current version of a child nested persistent > root, for example. > > I need to think about this a bit more... > >>>> Nested versioning (I believe) could be quite complicated to implement, but >>>> I'm happy to be proven wrong. >>> >>> I'm still playing with it, so we'll see. :-) >>> >>> My idea so far is: >>> >>> - it's built on top a simple store that doesn't provide any versioning, >>> unlike the store API in ObjectMerging >>> - the data model of the store is more or less the same as ObjectMerging: >>> objects with key : value pairs, and the objects can be organized in a >>> hierarchical structure (still not sure whether to do this like the way >>> ObjectMerging does, by marking certain keys as being 'composition' >>> relationships, or to have a special "children" key) >>> - versioning is achieved by copying an object and its children in the >>> hierarchy. The store is optimized so that the copy will be "cheap". >>> - to be useful, it needs to have a data structure to keep track of the >>> copied versions. This is the diagram Quentin mentioned earlier: >>> https://github.com/ericwa/NestedVersioning/blob/master/Docs/NestedVersioningDiagram.pdf?raw=true >>> - what's important is that the data structure for keeping track of versions >>> of an object is itself constructed of regular objects, so the data >>> structure for keeping track of the versions of an object could be part of a >>> larger tree which is itself being versioned - that's where the nesting >>> comes from. >>> >>> There is more brainstorming in the Docs directory on my github, but it may >>> not be very coherent. ok. I just have one comment. Although the history model is not the same than ObjectMerging… To navigate the history data structure (tracking the copied versions) quickly without loading it entirely in memory, I'd say you have to put in a database. Which means basically extending the store API with versioning (more or less in the same way than the ObjectMerging store API evolved between the first version and the latest), no? >> If there is no objection I'd like to rename COCollection to COGroup and >> merge the related code from CoreObject. In addition, I'd like to bring the >> CoreObject protocol once tweaked a bit to ObjectMerging and COFile and >> CODirectory. >> >> Once all this is done, I plan to move CoreObject to Deprecated and rename >> ObjectMerging to CoreObject. >> >> Any comments about all that? > > Personally, I want to sort out composite document support first - whether it > is extending ObjectMerging a bit, or building something new - because I'm not > really confident the current ObjectMerging model is sufficient. > > I don't want to stop you from working on ObjectMerging though, since we can > always merge code in the future. ok Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
