Warning !!! LeoPyRef.leo in the cd23a8c01f07 is corrupted

[vitalije]

As the title says, LeoPyRef.leo in the cd23a8c01f07 is corrupted. It contains two different nodes with the same gnx. The gnx in question is `ekr.20150605175037.1`. The node with this gnx exists in the leo/doc/leoAttic.leo and there it has a headline `** From leoCheck.py & checkerCommands.py`, while in the LeoPyRef.leo, the node with this gnx has headline `@file leoCheck.py`. Leo reads the external file from leo/doc/leoAttic.txt and changes the headline of the node, and later it is not found to be a `@file` node, so it is not read again. Besides leo/core/leoCheck.py is missing.

If one opens LeoPyRef.leo and saves it  without making any changes, git reports a huge diff.

Vitalije

[Edward K. Ream]

On Sunday, March 8, 2020 at 1:42:37 PM UTC-5, vitalije wrote:

As the title says, LeoPyRef.leo in the cd23a8c01f07 is corrupted.

What is the date of this rev?

Edward

[vitalije]

$ git log
commit cd23a8c01f073ac2901d42a571eda8217ab47aa9 (HEAD -> devel, origin/xml, origin/docks2, origin/devel)
Author: Edward K. Ream
Date:   Fri Mar 6 05:43:11 2020 -0600

    Remove traces

[Edward K. Ream]

On Sunday, March 8, 2020 at 1:46:14 PM UTC-5, Edward K. Ream wrote:

What is the date of this rev?

Oh, I see. It's the latest rev. I haven't updated LeoPyRef.leo recently, so maybe this is a long-standing issue.

I have just created #1526 for this.

Edward

[vitalije]

Oh, I see. It's the latest rev. I haven't updated LeoPyRef.leo recently, so maybe this is a long-standing issue.

In order not to forget to update public outline, I have a button in all my private outlines. This button is bound to Ctrl-s. It's body contains calls to both c.save() and c.fileCommands.save_ref(). In my private files I have set reference file using command `set-reference-file` to the public version. So, whenever I click Ctrl-s to save my private outline, public outline gets updated too. The only thing I have to remember is after pulling other's changes, I need to execute 'read-ref-file', to synhronize my private outline with the public one.

While I am writing this, I have an idea. After opening private file, it can check that the contents of the public file is the same as the public part of the private file. If they are not equal, then it should remind me to read-ref-file. This can be done in a plugin. Hope to write it soon.

Vitalije

[Edward K. Ream]

On Sun, Mar 8, 2020 at 2:07 PM vitalije <vita...@gmail.com> wrote:

Oh, I see. It's the latest rev. I haven't updated LeoPyRef.leo recently, so maybe this is a long-standing issue.

In order not to forget to update public outline, I have a button in all my private outlines. This button is bound to Ctrl-s. It's body contains calls to both c.save() and c.fileCommands.save_ref(). In my private files I have set reference file using command `set-reference-file` to the public version. So, whenever I click Ctrl-s to save my private outline, public outline gets updated also. The only thing I have to remember is after pulling other's changes, I need to execute 'read-ref-file', to synhronize my private outline with the public one.

While I am writing this, I have an idea. After opening private file, it can check that the contents of the public file is the same as the public part of the private file. If they are not equal, then it should remind me to read-ref-file. This can be done in a plugin. Hope to write it soon.

Thanks for these comments.

How did you discover the problem with LeoPyRef.leo?

Edward

[Edward K. Ream]

On Sunday, March 8, 2020 at 1:42:37 PM UTC-5, vitalije wrote:

As the title says, LeoPyRef.leo in the cd23a8c01f07 is corrupted. It contains two different nodes with the same gnx. The gnx in question is `ekr.20150605175037.1`. The node with this gnx exists in the leo/doc/leoAttic.leo and there it has a headline `** From leoCheck.py & checkerCommands.py`, while in the LeoPyRef.leo, the node with this gnx has headline `@file leoCheck.py`. Leo reads the external file from leo/doc/leoAttic.txt and changes the headline of the node, and later it is not found to be a `@file` node, so it is not read again. Besides leo/core/leoCheck.py is missing.

I don't see any such problem. The second comment of #1526 contains two scripts that pass.

Edward

[vitalije]

The problem can't be seen using Leo. When Leo opens this outline it overwrites clones (as it should do), so the final result is the same node. The difference is inside the xml content of the LeoPyRef.leo. This problem doesn't prevent Leo from normal functioning. It just makes a large diff if saved without any changes. I suppose it would be enough to commit those changes, but I am not sure which version of the two conflicted nodes would you rather keep.

Vitalije

[Edward K. Ream]

On Mon, Mar 9, 2020 at 1:06 PM vitalije <vita...@gmail.com> wrote:

The problem can't be seen using Leo. When Leo opens this outline it overwrites clones (as it should do), so the final result is the same node. The difference is inside the xml content of the LeoPyRef.leo. This problem doesn't prevent Leo from normal functioning. It just makes a large diff if saved without any changes. I suppose it would be enough to commit those changes, but I am not sure which version of the two conflicted nodes would you rather keep.

Thanks for this. I have reopened #1526.

Edward