Terry congratulated me on fixing #76 erroneous clone markers in @auto trees. The celebrations are premature.
It's easy to see at least one flaw in the present gnx allocation code: the post-pass calculates ni.lastIndex after reading all external files **including @auto nodes**. But suppose the @auto node contains a new node (a node created outside of Leo). The @auto read code will *immediately* allocate a gnx for the new node. This happens before the post-pass runs, so the newly allocated gnx could clash with a previously allocated gnx! Yes, this can only happen if the present invocation of Leo clashes with a previous invocation of Leo. (Two invocations of Leo **clash** if both are based on the same timestamp.) We all now agree that clashes *do* happen. The post-pass was supposed to be a workaround. But we shall soon see that it isn't. My first thought was to delay the allocation of new gnx's until after the postpass. Like this: 1. ni.getNewIndex would allocate None as the gnx if it is called before the post-pass. In that case, getNewIndex would add the vnode with the dummy gnx to a global list. 2. After the post-pass, all nodes on this list would get a proper, safe, gnx based on the updated ni.lastIndex. But this is all delusion! Consider these itsy-bitsy teeny-weeny questions: 1. How many .leo files did the previous clashing invocation of Leo open? 2. When is *this* invocation going to open all the files opened in the *other* invocation of Leo? Oops! Leo can only run the post-pass after we open *all* the .leo files opened by the "clashing" invocation of Leo. But Leo has no idea what those .leo files were! As a result, Leo can *never* be sure a .leo file that is opened *after* the post-pass won't contain gnx's that clash with newly-allocated gnx's in *this* invocation of Leo. This problem has no solution: it is always too early to run the post-pass! Leo must create unique gnx's without using a post-pass. Terry's Aussie brother Tony reminds us that *no* timestamp format, no matter how fine-grained, can guarantee that timestamps will *never* collide. I doubt that SegundoBob's timestamp-adjusting hack will suffice either in general. It seems that the *only* solution is to use uuid's for all newly-allocated gnxs. This would eliminate the harmful effects of clashing invocations. Indeed, the notion of clashing invocations disappears if Leo doesn't base gnx's on timestamps. Your comments please. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
