Zero and Single Source Clones Considering “zero source clone” we do not have any problem at all. Since Leo is the only one that manages the content of the clone nodes, it makes sure that all clone nodes are in sync all the time (bugs permitted). Attempting to modify the Leo XML file out side of Leo is always a high risk operation, but actually, Leo's XML data structure protects us from causing clone problems by keeping only a single copy of the clone entity's content. Thus, if this content in edited directly outside of Leo, it will change the content of all corresponding clone node. I.E. no problems at all.
Now we are ready to consider “single source clone”. This type of clone primarily corresponds with the first use case “clones for convenience” (as does “zero source clones”). For this type of clone it might be the case that the content of the “external node” becomes out of sync with the rest of the clone nodes that Leo manages. Since the other clone nodes are typically copies of the “external node” for convenience, it is quite rational to update them when Leo detects a change in the content of the “external node”. This is what Leo implements today with its strategy of “last node wins”. Since Leo file reads the .leo file (with all the clone nodes in it) first and only then starts reading derived files, the “external node” is read last and the rest of the clone node are updated to its content. Easy, simple and efficient. (By the way, in a future implementation, if one wants to prevent this auto-update of the “internal nodes”, it can be done simply by keeping a node of the clone in a “junk” file, forcing the clone to be “multi source clone”, see next.) -- 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.
