Hi Quentin On 28/10/2011, at 20:03 PM, Quentin Mathé wrote:
>> I think that branching in the second case is not always necessary, but it >> should probably still be possible. As I outlined in my previous email, an >> option was to hold an object at a revision, but still have it track the >> branch and allow it to be updated manually. I think embedding it completely >> (i.e. coping the whole object in as an embedded object), at least in the >> case of a photo montage is not good, as it would consume alot more resources. > > I agree about branching being not always necessary in the second case. > > For embedding it completely, this only makes sense with Nested Versioning I > suppose. From what I have understood, Nested Versioning would implement > embedding as branching, the store would create cheap copies (or branches) > when a root object is copied. Ah ok. I get it a bit better now. >> 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. > Another point worth to mention is the fact that almost no users will use > branching I think. Let's suppose Étoilé ends up with the same audience than > Mac OS X or Windows. I doubt that more than 5 or 10 % of the users will ever > use the branching ability. For these users, it's going to be a very important > feature though. > My doubts about automatic branching are based on the troubles I get into when > I try to explain branching to people with various computer experience levels. > I get replies such as "why making copies is not good enough to work on > document variations". If I explain you cannot merge the changes, the reply > might be "merging changes would be nice but I'm not interested in this > 'branch' concept. I just want to create copies and merge changes." > I now think this informal approach to branching might be a better way to > expose the users to it without too much mental burden. This makes me realize > the important thing is the "merging" support rather than the "branching", and > branches and copies should really be equivalent. > For users who knows about branches and wants to organize things cleanly, we > could provide some UI that exposes the branch concept and the possibility to > turn copies into branches or vice-versa. This would act as a thin > organization layer that remains optional. I completely agree. I always envisioned the idea of creating a branch with a commit track was equivalent to creating a copy of an object, but without cloning the whole history. >>> 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. For this, would we just add a UUID to the commit track and call it the "root object"? 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. Regards Chris -------- Christopher Armstrong [email protected] _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
