On Aug 25, 8:40 am, "Edward K. Ream" <[email protected]> wrote:
> I am running into complications with the one-node world. This is no > great surprise. The one-node branch now contains the latest work. Be careful: the code is actively dangerous when g.unified_nodes is True. The problem with caching is perhaps only a symptom of a deeper problem, namely, how to synchronize leoProjects.txt. This problem gets quite severe when working on several branches at once. It's gotten so bad that I don't want to drag info into leoProjects.txt, but that's not good either: it's too easy to lose info (the view, not the actual nodes) when using bzr pull --overwrite. As we have seen recently, the order in which Leo reads external files can cause strange-looking problems. I think Ville may be right that we need some precedence mechanism to govern which clone will override other clones. The "last clone read" rule may be too confusing. But I don't see a good, simple, solid solution. Another way to state the problem, is that resolving bzr conflicts in "structured" files is not easy. The compare-leo-files commands is supposed to help, but it's not working, at least not in the one-node branch. All this is actually quite upsetting. Similar problems must exist even in vanilla (flat, non-Leo) files, but I suppose the addition of Leo sentinels makes the task of resolving bzr conflicts harder. Would the problem be simpler if all branches used the same leoProjects.txt file? Well, perhaps in some ways, but mixing clones from different branches seems like not such a hot idea :-) Clearly, more invention is needed. Edward --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
