All about clone conflicts

[Edward K. Ream]

Some people seem to think that it is difficult to understand how Leo
handles "clone wars": differing values for a cloned nodes that appear
in several external files. That's not true. The rule is::

**The last clone that Leo reads wins.**

That is, for any cloned node C, Leo takes the value of C.h and C.b to
be the values specified by the last copy that Leo reads.

There is only one complication::

**Leo reads the entire outline before reading any external
files.**

Thus, if C appears in x.leo, y.py and z.py, Leo will choose the value
for C in x.py or y.py, depending on which @<file> node appears later
in the outline.

Notes:

1. Whenever Leo detects multiple values for C when opening an outline,
Leo creates a "Recovered nodes" tree. This tree contains all the
various values for C, nicely formatted so that it is easy to determine
where the differences are.

2. I've just refreshed my memory by looking at the code. The relevant
methods are:

fc.getLeoFile # Reads the outline, then calls at.readAll to read
all external files.
at.indicateNodeChanged # Adds data to c.nodeConflictList
cacher.reportChangedClone # Adds data to c.nodeConflictList
fc.handleNodeConflicts # Creates "Recovered Nodes" node and its
children.

3. The present code is the simplest code that could possibly work.
There is no way Leo is going to do AI in order to implement complex
rules for which clones are "more important" than others. Thus, if you
use cross-file clones, it is up to *you* to know these rules and
handle any resulting conflicts. Imo, the "Recovered Nodes" feature is
a big step forward for Leo, and makes it impossible to lose data
unless you willfully refuse to examine the data.

Edward

[Joon Ro]

Hi Edward,

Thanks for the explanation. As a matter of fact, I was having hard time understanding this. 

I had my source file in a @shadow node, and then I had a backup of that file as @file node, which had clones of the nodes of the source @shadow file and some other codes that I stashed. 

Whenever I changed the source code externally with leo closed, when I open leo, it made recovered nodes. The problem was since @file was placed "later" in the outline, leo kept putting the new changes I made to old, instead of new.

Now I understand how this works. but I think in multiple external file cases, it would make more sense if leo checks the file modification time when it makes decision which node is new, instead of just depending on the order of files in the outline. In above case, it is natural for me to have actual source nodes on the top of the outline and backup nodes on the bottom. Please let me know what you think. 

Best regards,

Joon