Multi Source Clones This is the difficult case, which is typically associated with the second use case “clones for synchronization”. This is a powerful clone type, which a user chooses to use and needs to be able to manage properly and responsibly. The problem with “multi source clone” is obvious – multiple clone nodes may be changed outside of Leo, causing clone sync to break without an automagical method to fit and fix all scenarios.
Let's start with what will probably be the most common case: all clone nodes are in sync but one external node. This out-of-sync clone node may not be the last clone node to be read, and Leo _must not_ change its content or the user will loose touch with the real code. We are in a situation in which there are two versions of clone content for the same clone entity. Let's call the version of the out-of-sync clone node version 1 and the version of the rest of the clone nodes version 2. Assuming that this situation is properly flagged by Leo (see below) and given some Leo tools to resolve this situation (see below as well), the user might want to: i. de-clone the out-of-sync clone node thereby converting it to a regular node, ii. change the content of the out-of-sync clone node to content version 2, or iii. make the content of the out-of-sync clone node (version 1) the content of all clone nodes thereby discarding version 2. The user will choose i. if indeed the content of the out-of-sync node should no longer be the same as the other clone nodes (i.e. the second use case is no longer relevant for this node). II. will be selected if the user determines the change of the out-of-sync node to be accidental (i.e. the user reverts the content to enforce the synchronization constraint). III. is the right choice if the user determines that the change in the out-of-sync clone node is appropriate and due to lack of use of Leo the person making that change neglected to appropriately propagate it to all the right places. To make things even worse, this simple scenario may be further complicated by option iv. change the content of some of the other clone nodes to that of the out-of-sync node (version 1). This might happen when some of the clone nodes are actually “clones for convenience” of the out-of-sync clone node, while other clone nodes are “clones for convenience” of at least another external node (otherwise this would not be a “multi source clone” type). To summarize, the following are useful options for the user to have: a. De-clone this clone node (making it a regular node and keeping its content version x). b. Split-clone all clone content version x nodes (keeping them as clones with content version x). c. Re-sync this clone node with clone content version y (replacing this node x by y). d. Re-sync all clone content version x nodes with clone content version y (replacing all x by y). e. Re-sync all clone content version y nodes with this clone content (replacing all y by x). It may sound confusing at first, but simply put it is: turn A to B and get rid of A (or vice versa), keep A and B separate, or just handle this particular node. -- 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.
