clone wars revisited
HansBKK
I've also be writing the "backup tree" out to a file on another filesystem, but in browsing past threads I see this is not a good idea. The clearest discussion on this is from a long time ago:
https://groups.google.com/forum/#!searchin/leo-editor/multiple$20clone$20nodes/leo-editor/wulhmob-Ne4/ywbiBUQpo5oJ
This from Edward:
> I don't recommend saving clones in multiple non-@all external files.
> In other words, Imo, the most important distinction is between external files containing @all and external files that don't.
> My suggested rule is this: when putting clones in external files, make sure the clone appears in at most one external file that does not contain an @all directive.
> Leo's new read code gives top priority to clones in external files not containing @all. The new read code gives lowest priority to clones in external files that do contain @all.
My questions:
Does the above still hold?
If I am sure the backup tree file will never be modified externally is that safe from the anticipated problems? It is certain the main target file **will** be modified externally, which is why I'm trying to protect its tree from being flattened within/by Leo.
I could just use @all in the backup tree, but I've been re-ordering children by moving their section labels in the parent and not bothering to re-sequence them in the tree, so I'd have to go back and get everything back in sync in the "master" first.
I suppose the safest would be just to trust Leo to the point where the second tree doesn't get written out to disk at all.
Guidance on this would be most appreciated. . .
HansBKK
Trying another approach - first clarify my case, more general that the "backup trees" discussed above:
A - "master" tree - imported from external source files, **should** never be updated within Leo, as I break it down into chunks with sections/@others, I constantly write the files back out using @shadow and diff against the checkout to ensure my Leonized representation continues to output exact matches with the original files.
B - "custom" trees - a re-factored mix of cloned nodes from A and original content. If necessary can set as SOP that the custom nodes are **only** edited within Leo - obviously the contents of the cloned-from-A ones aren't touched at all.
The B trees do need to be "published" back out to the filesystem, but I've found that using @shadow here results in entire trees's worth of nodes getting destroyed, either flattening everything into the parent body, sometimes leaving content only out in the filesystem.
Restricting the B tree's @ <file> nodes to @all - the approach recommended two years ago, waiting confirmation if still applies
> My suggested rule is this: when putting clones in external files, make sure the clone appears in at most one external file that does not contain an @all directive.
Questions
- Do you think this approach is safe? Any cautions to add to the SOP?
- Any thoughts on an alternative path?
If this works, then it should handle the "backup trees" being written out to the filesystem as well.
Edward K. Ream
> I've been trying to create "backup nodes" - copy-not-cloned parents
> containing all the clones of an important @shadow file that has been
> "flattened" in the past when updated externally, with a goal of trying to
> preserve the outline structure, or at least assist me in rebuilding it if
> necessary.
It's hard to comment on complex proposals such as yours. I am not
likely ever to implement any such proposal, and certainly not this
calendar year.
The worst mistake I ever made with Leo was the notion of "backup" .leo
files. It lead to impossible-to-predict data loss at arbitrarily long
limes after the backup files were created. I am not likely to do
anything similar ever again.
I just came across a situation in which an @shadow tree got flattened.
It happened because a unit test mistakenly deleted a private shadow
file.
Keeping this in mind, here are two different backup plans that you can
do immediately, without changing Leo in any way:
1. Just copy the @shadow tree, and paste it elsewhere (perhaps in
another .leo file), changing @shadow to @@shadow in the pasted
location. This stores all info in the .leo file.
2. Make copies of the private files in the .leo_shadow directories. I
have just verified that Leo's import-file command will indeed recover
the information in .leo_shadow directories.
Either way should safely preserve all the essential information.
HTH.
Edward
HansBKK
It's hard to comment on complex proposals such as yours. I am not
likely ever to implement any such proposal, and certainly not this
calendar year.
The backup issue isn't so important at this point compared to my furthering that understanding, and I'm collecting detailed notes and hope to take advantage of my current noob POV to add relevant howto's to Leo's docs one day.
To generalize my scenario further, only using @shadow or @nosent, all data is in either "A" or "B" trees.
The "master" tree "A"
- is the only one containing @shadow files
- there are no clones shared between them
- only those files will be edited externally
All other locations "B"
- contain only @nosent files
- all changes to their content take place within Leo
I believe the above guarantees that for any given node, only one location is subject to two-way read/writing at all; this SOP seems in fact **more** verifiable and secure than the "only use @all in B" rule.
I'm not asking for any blanket assurances, I'm happy to take full responsibility, but does this seem sound in principle?
Or if not from "you Edward" on this specific question, any feedback from "you anyone" would be greatly appreciated.
I've been doing some testing, admittedly not exhaustive, but so far things seem OK.
Edward K. Ream
> I'm sorry if I implied I was asking for anything but information and advice,
> much less for any changes in Leo's functionality; I'm honestly just trying
> to figure out how to reconcile what I'm trying to do with my understanding
> of the various facilities Leo offers.
Oh. I misunderstood.
> To generalize my scenario further, only using @shadow or @nosent, all data
> is in either "A" or "B" trees.
>
> The "master" tree "A"
> - is the only one containing @shadow files
> - there are no clones shared between them
> - only those files will be edited externally
>
> All other locations "B"
> - contain only @nosent files
> - all changes to their content take place within Leo
This looks safe to me, now that you mention it :-) Please let us know
how it works for you.
Edward
HansBKK
This looks safe to me, now that you mention it :-) Please let us know
how it works for you.
If this proves to be a solid solution (after more systematic testing) to the oft-expressed desire for "multi-file" clones, I recommend that this be reflected in the @ <file> docs. Note of course it still does not enable "multi-source" clones. Perhaps call this "single-source multi-target" cloning?
Consider this to a somewhat delayed response to this post, and let me know if it rings any bells:
http://groups.google.com/group/leo-editor/msg/c54658a6ea61d52f
I believe nothing actually got modified in @sent's logic as a result of the thinking behind this post?
The docs somewhat deprecate @nosent, but it seems my use case may restore them to full-fledged citizens. Note that this only works **because** Leo can't read from them.
--------------------
At the risk of being a pest, I'd still like to request - no rush, and only if it's easy - a response to this question:
>> My suggested rule is this: when putting clones in external files, make sure the clone appears in at most one external file that does not contain an @all directive. Leo's new read code gives top priority to clones in external files not containing @all. The new read code gives lowest priority to clones in external files that do contain @all.
It's not just an academic question, as I am considering other scenarios where it would be valuable for a snippet in the B tree to be updated externally. In this case it would be worth sacrificing the control offered by sections/@others ordering, in order to get true "multi-source" clones.
HansBKK
Many hundreds of files later, haven't had any problems with this SOP to avoid clone-war data loss.
All of the below still applies.
If this proves to be a solid solution (after more systematic testing) to the oft-expressed desire for "multi-file" clones, I recommend that this be reflected in the @ <file> docs. Note of course it still does not enable "multi-source" clones. Perhaps call this "single-source multi-target" cloning?
Consider this to a somewhat delayed response to this post, and let me know if it rings any bells:
http://groups.google.com/group/leo-editor/msg/c54658a6ea61d52f
I believe nothing actually got modified in @sent's logic as a result of the thinking behind this post?
The docs somewhat deprecate @nosent, but it seems my use case may restore them to full-fledged citizens. Note that this only works **because** Leo can't read from them.
--------------------
At the risk of being a pest, I'd still like to request - no rush, and only if it's easy - a response to this question:
>> My suggested rule is this: when putting clones in external files, make sure the clone appears in at most one external file that does not contain an @all directive. Leo's new read code gives top priority to clones in external files not containing @all. The new read code gives lowest priority to clones in external files that do contain @all.
>Does the above still hold?