Hmm ... well at least it seems reproduceable. I did run across at least one set of nodse after filing this that were behaving as clones but not flagged as clones, and it's probably the same ones. Not sure if it matters but the box icon was grey instead of black, I thought that was unusual as well, but not sure what that indicates I'm using the sqlite version because I assumed it could offer better performance for very large outlines (e.g. potentially 50K+ nodes). Also, because I like SQL and can connect to it with DBVisualizer/alternate tools and write queries (read only ones for now) and/or use ETL workflows with it. One thing that _might_ be happening is that I have a 'code' top-level tree that syncs with other developers using Git.It's using @file's and so there are now comments scattered throughout the code base. Then subnodes within this tree are cloned into @nosent 'documentation' trees which contains other notes/commentary outputs.This is mostly doing what I want, but importing the nodes sometimes results in errors/broken outlines/etc, which I have to repair.I close Leo, do the pull, then open Leo again and let it import. Then I fix any issues (mostly nodes losing their parents and appearing at the root).I also keep an eye on Git to ensure that I'm not making any unwanted changes after doing this and can revert if necessary.It's possible that other developers are copying/moving blocks of code that include the Leo comments (I've asked them not to do this).We're making a lot of structural changes now too as we're refactoring so this should settle down later. For now, perhaps I can save as .leo and then save back as .leo.db to potentially repair any issues. Is it perhaps possible to detect and/or repair these broken clones using a script? Thanks so much for all your help. Kevin
On Thu, 2020-09-03 at 11:52 -0700, Edward K. Ream wrote: > On Wednesday, September 2, 2020 at 3:24:45 PM UTC-5, k-hen wrote: > > > Ok, got it, will need a bit of time, but will get back to you soon. > > Something strange is going on. Here is what I think I know: > > The unpacked original file is leo_error_test_01 - cleared - Copy.db. > It is about 28.1 MB in size. > > Opening the file with Leo does work, but the two "node 5660" are not > shown as clones of each other. Yet they have the same gnx and id(v) > is the same for each. Imo, this is likely the ultimate cause of the > crash. > > Saving this .db as a .leo file creates a valid .leo file in which the > two "node 5660" are indeed true clones. The bug never appears in the > .leo file. > > Saving the .leo file as a .leo.db file creates a much smaller file, > about 1.2 MB. However, in all other respects it appears to be > identical to the original .db file. The two "node 5660" are not shown > as clones of each other, and the bug does manifest itself. > > My tentative conclusion is that there may be a bug in > fc.retrieveVnodesFromDb. However, there are no special cases in this > code, so what the bug could possibly be is a big mystery. Iirc, > Vitalije wrote this code. Any insights would be appreciated. > > Finally, I note that the .leo files are smaller than the > corresponding .db files, so one workaround would be to use the .leo > files instead. Presumably, however, there are reasons for using the > .db files. > > Edward > > > > > -- > > You received this message because you are subscribed to a topic in > the Google Groups "leo-editor" group. > > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/leo-editor/sANduRjZDVI/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/leo-editor/9afd5fe4-7fd3-4e68-91d7-283f02367601o%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/2c4906311bc48e909c60b3d7bb4fc0446b87bb78.camel%40gmail.com.
