On Fri, Mar 2, 2012 at 10:15 AM, Seth Johnson <[email protected]> wrote: > On Fri, Mar 2, 2012 at 10:04 AM, Edward K. Ream <[email protected]> wrote: >> ===== The synchronization problem >> >> There is a potentially fatal problem with this scheme. Any time *any* >> data is composed from multiple sources, the question arises, >> >> what happens if the two sources get out of synch? >> >> For example, what happens if I commit an external file, but not the >> file containing the associated @test nodes? Later, when somebody else >> reads the external file into Leo, at least two problems can occur: >> >> 1. The node referenced in the #@include sentinel will not be found at >> all. >> >> 2. The node will be found, but will be out of date. >> >> Leo can detect the first problem because #@include sentinels give a >> gnx. >> >> Leo could detect the second problem it the #@include sentinel >> contained a time stamp. >> >> It's not clear, however, that merely detecting the problem is enough. >> This might be an example of a beautiful theory being killed by an ugly >> fact. However, I'm not ready to give up on tag files just yet ;-) > > > Might this be solved with the general idea I've been describing, of > distinguishing @file from something like @template, where you would be > allowed to clone in pieces from other sources? Let @file only refer > to its own single external file. The synchronization problem becomes > self-evidently resolved: @file, being the actual source, takes > precedence over any compositions under @template nodes -- the user > recognizes that @template nodes are virtual and updated by the origins > of their contents.
Well, maybe not solve it, but it may suggest an approach to the general problem. Seth -- 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.
