On Mon, Jun 8, 2009 at 9:12 PM, Edward K. Ream<[email protected]> wrote:
> What I want to avoid is a situation in which two different .leo files or > @thin nodes each have a presumptive claim to "own" a node. Well, here the one that comes first owns the node, which can suddenly change when you reorganize the tree. Actually, the way I implemented clone support for hash caching is suggests that nodes that claim ownership of a tnode *first* take precedence (and amazingly, it seems to work). That is, when you read in a tree and see that this tnode already exists, you do not read in the content but just create the clone to an already existing node to that spot. That felt more intuitive to code than recreating the whole tree and overriding previous clones. Apparently, that was wrong ;-). I'll correct this. > That's highly unlikely to happen, because qtNotes.txt will likely be in > synch with all the .py files when you commit. The only thing to avoid would > be to make external changes in qtNotes.txt rather than the "primary" files. I (almost) never commit to qtNotes.txt, because I expect there to be several collisions with your modifications. Likewise, I (almost) never commit to .leo files for the same reason. I have very little desire to resolve merge conflicts in files like that, since that proves to be problematic more often than not. >> Also, perhaps there should be a loud warning >> when the user does this. It's a fact of life that in VCS environment, >> files *will* get out of sync. > > I'm not sure what you mean by "this", but I don't recall any serious > problems with qtNotes.txt. Probably because it's less authoritative than .py file. > You are right to be a bit concerned about cross-file clones. And a comment > in the @root qtNotes.py node saying that the node should precede all other > @thin nodes would be a good idea. But I don't think any other action is > needed. Apart from me fixing hashcache functionality, that is ;-). BTW, regarding hashcache - I changed it to use compressed (zlib) pickles, resulting in 75% space saving (and apparently some improvement in performance). This means you need to rm -Rf ~/.leo/db -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
