On Sun, Jan 24, 2010 at 3:04 PM, Gil Shwartz <[email protected]> wrote:
> Clone Terminology
>
> 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.

In the one-node world, all joined nodes are the *same* node.  This
includes clones, but it also includes all descendant nodes of clones.
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.

> 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.

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

-- 
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.

Reply via email to