A bit of a drawback to the current Recovered Nodes scheme is the fact
that nodes content is modified on load. While Leo politely informs on
this in the Recovered Nodes, I'd rather prefer that at least for
"Multi Source Type" clones, it would keep the read content intact.

How about the following meta code:

Initialize cloneConflict data structure to empty.

Read .leo file and build internal clone, if any (this is always
consistent).

For each loaded file
  Read the file and build its tree.
  If clone conflict found
    If clone id already in cloneConflict
      Scan clone versions for that id to determine if new content
matches known clone content version.
      If match found, assign the clone id of this version to the new
clone node (the one that is read from the file).
      Else, create a new clone (version) id and assign to the new
clone node (that is read from file).
    Else
      Add clone id to cloneConflict as key with value as array of
clone version ids (each version hold the files that include node(s)
with that version).
      If the existing content was read from file(s), add it as a
version (otherwise it is version 0 - the internal content).
      Create a new clone (version) id and assign to the new clone node
(that is read from file).

After all files were load ...
If cloneConflict is not empty
  Create "Recovered Nodes".
  For each entry in cloneConflict
    Add a node (call it Clone X, according to the clone name/id) under
"Recovered Nodes".
    Add a clone node under Clone X cloned to the clone id (version 0)
[or "No internal clone nodes"].
    For each other clone version
      Add a node under Clone X by the name "Version i", with the
content being the list of files the include this version.
      Add a clone node under "Version i" cloned to that clone
(version) id.

The meta code above shall create the following "Recovered Nodes" tree
for the bug described above:

Recovered Nodes
+ Clone Gil.12345
++ "No internal clone nodes" (if we had internal clone nodes, this
node would be a clone to them)
++ Version 1 - content is the name of file 1
+++ [Version 1] (an actual clone with id Gil.12345) - content is A1
++ Version 2 - content is the name of file 2
+++ [Version 2] (an actual clone with id Gil.12346, or Gil.12345.1,
whatever) - content is A2
++ Version 3 - content is the name of file 3
+++ [Version 3] (an actual clone with id Gil.12347, or Gil.12345.2,
whatever) - content is A3

Advantages:
1. The original content read from the files is preserved in Leo's tree
representation.
2. All versions of the same clone are documented clearly with the
exact relationship between them.
3. It is easy to decide to make changes to a node is a specific file
since we can just modify the node in that file (go to next clone).
4. It is easy to decide to make knowledgeable changes to all nodes of
a clone version since they are all cloned under Recovered Nodes.
5. It is easy to define logical actions for the version nodes.
5.1 Merge marked to selected version - modify the clone id of nodes
from the marked version ids to the clone id of the selected version.
5.2 Merge all to selected version - modify the clone id of all nodes
from all versions to the clone id of the selected version.

We can also have an "auto update" option for the case of "Single
Source Type" clones. This would verify that a clone has only one other
version beside version "0", which would mean that the internal nodes
conflict with the version of the externally updated node(s), and would
update the content of the internal nodes only.

With the auto update option, this proposal is equivalent to the
current behavior of Leo for the simple common cases, while giving
power to more complex situations in (I believe) a robust way. Almost
no modification to the load code, very clear data structure, very
clear representation (somewhat similar and I think more informative
than the current "Recovered Nodes"), and simple actions (either use
existing declone action), or just add two, essentially the same,
operations using existing Leo tools - marks.

Comments :)

Gil

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