Gui Suggestions I think it is important to differentiate between “zero” and “single” source clone types and “multi source clone” type. This can be done easily by using double clone arrow for the latter clone type. Every time a clone node is moved, Leo can evaluate if it becomes an external clone node and if it does and the clone entity has more than one external clone nodes, it will change the single clone arrow to a double one (of course, doing vice versa when a clone node becomes an internal clone node and there are only 0 or 1 external clone nodes). It is worth noting that typically at the time of creation, a clone will be “multi source clone” (if the cloned node is external, immediately there are two clones in the same file). Later when one clone node is moved elsewhere, many clone entities will become “single source clone” types.
To assist in resolving clone conflicts (only existing for “multi source clone” type), the version of each clone node should be known to the user. The easiest way is to visualize it, e.g. by adding the version number to the node's box. I do not anticipate most conflicts to include many versions, but the solution should be reasonably general. I believe it should be accompanied with some helpful goto node functions: 1. Goto to next conflicting clone (moves between clone nodes of different clone entities which have conflicts). 2. Goto the next clone node (moves between clone nodes of the same clone entity). 3. Goto the next same version node (moves between clone nodes of the same clone content version). 4. Goto the next other version node (moves between clone nodes of the different clone content versions). For a healthy clone, 2 & 3 are the same and 4 does nothing. I think 2 is useful in general for any type of clone. I further find a suggestion previously made by others – creating a “clone for convenience” of the conflicting clone nodes – useful, and would like to expand on it. In case of conflict, it might be useful to create a tree with the following structure (maybe, as suggested, at the top of Leo's tree): - Conflicting clone 1 -- Clone version 1.1 --- File abc.c ---- <name of clone node> - this body contains clone content version 1.1 --- File def.c ---- <name of clone node> - this body contains clone content version 1.1 -- Clone version 1.2 --- File ghi.c ---- <name of clone node> - this body contains clone content version 1.2 - Conflicting clone 2 -- Clone version 2.1 etc. I suppose that in most cases there will only be 1 conflicting clone with 2 content versions. There might be a lot of conflicts if the code went through a major restructure, but indeed this should probably break the existing “clone for synchronization” constraint. -- 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.
