> > When talking about a clone we need to differentiate between the nodes
> > in Leo's tree that share the same textual content and sub-tree, I'll
> > call them “clone nodes”, and the logical entity which is the clone
> > itself, so to speak, and is represented in Leo by a GNX (a unique
> > global identifier), I'll call it “clone entity”.
>
> This is non-standard terminology. I'm not sure I approve.
Sorry about that - I just needed to invent some terms to help
differentiate between different cases and to explicitly name thing. I
felt that "clone" is used to too many parts of the concept. I am
willing to adopt any terminology you feel comfortable with, as long as
it has distinctions for the various parts that play in a clone to we
can discuss them clearly.
> In the one-node world, all joined nodes are the *same* node. This
> includes clones, but it also includes all descendant nodes of clones.
I completely agree. This is what I meant by "share the same textual
content and sub-tree", but you probably describe it better.
> For example,
>
> - A'
> - B
> - A'
> - B
>
> It's important to understand that while the two instances of A and B
> may look like different nodes on the screen, in fact, both "copies" of
> A are the same node, as are both copies of B. Internally, the graph
> looks like this:
>
> Hidden Root Node [A,A]
> A [B]
> B [ ]
>
> Here the [ ] notation denotes the children array of the node. So the
> hidden root node contains two "pointers" to A. That's what makes A a
> clone, in essence.
The Hidden Root Node is what I called the "clone entity". The "clone
nodes" are the two occurrences A', which are different nodes in the
tree. The content of A, including B and its content, are the "clone
content" (or later "content version").
> > Furthermore, there
> > are 3 different clone types to consider. I call the first “zero source
> > clone”. This is the type of clone in which all clone nodes are managed
> > exclusively by Leo (“internal nodes”), i.e. none of the clone nodes
> > are a child of a file that is read back by Leo. The second is “single
> > source clone”. For this clone type, only one clone node (the “external
> > node”) is a descendant of a file that is read back by Leo, i.e. this
> > type of clone has only one clone node who's content may be changed
> > outside of Leo. The third and last clone type is “multi source clone”.
> > This is the most problem prune clone type and it has two or more clone
> > nodes who's content may be changed outside of Leo's control (“external
> > nodes”). These may even be two clone nodes in the same derived file.
>
> Again, this terminology is non-standard. Leo doesn't have anything
> internally that corresponds to this. The distinction, if one can call
> it that, is enforced by Leo's read code, which in several places
> decides what to do if two definitions of a node clash.
Of course Leo does not represent this internally. I think some of this
is new and represent a chance to further develop Leo.
Indeed the read code is a player in the clone game, but other parts of
Leo should participate as well. The thing on which the read code has a
monopoly on is the detection of clone conflicts and the creation of
whatever is decided that will help in clone resolution. This is yet to
through more discussion.
> I agree that it may be good to be aware of this distinction when using
> Leo. But Leo must work well even if users have no idea about this
> distinction :-)
>
> Edward
I totally agree. Many users will only use Leo clones for views ("clone
for convenience"), if at all. This will also result the current Leo
graphical representation - a single arrow. It will also never result
clone conflicts. However, we do not want these users to trip naively
on a clone trap, and the more advanced users might want to use Leo in
a more advanced way. I think Leo should be able to support them, and
therefore having this distinction explicitly is important (as a clones
user I was not aware of this until I wrote this overview). My believe
is that Leo should provide the tools and graphical representation to
differentiate and manage the more complex cases as well.
Gil
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
