On Mar 27, 6:46 am, "Edward K. Ream" <[email protected]> wrote:
> I am steadfastly refusing to get excited about @file! until all > questions are fully resolved. Hand waving will not do. Standing in the shower a few minutes ago I saw the essence of the situation. I am now officially starting to allow myself to get excited :-) The big Aha is that there is *no need* to keep public and private files in synch. Indeed, in an environment in which not everyone uses Leo, it is *not possible* to keep files in synch. But that doesn't matter! There are only two real cases to consider: Case 1: A public file is committed, but not the corresponding private file. Case 2: A private file is committed, but not the corresponding public file. Let's consider what will happen if somebody does an bzr merge or pull in each situation. Case 1: The user will get the updated public file. If the user doesn't use Leo, the user will still get the "useful" version of the file. If the user *does* use Leo, the next time the user reloads the relevant .leo file, Leo will use the full @shadow algorithm to update the corresponding private file. Of course, the "real" private file won't be available, but so what? At most some structure info will be lost. Case 2: The user will get the updated private file. If the user doesn't use Leo, it will be as if nothing got committed. If the user does use Leo, the @shadow logic will see that the private file is more recent than the public file, so the @shadow logic will *ignore* the old public file and use only private file. I believe that in each case, Leo will continue to work when the "laggard" file is eventually committed. I suppose there are some "round trip" proofs involved, so not all the i's have been dotted and the t's crossed, but I don't anticipate problems. In short, there is *no need* to keep public and private files in synch. It's not possible anyway, because non-Leo users will *never* commit private files. I believe that this may indeed solve the problem that I have been working on since approximately 1996. 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 -~----------~----~----~----~------~----~------~--~---
