On Mar 26, 11:27 am, "Edward K. Ream" <[email protected]> wrote:
> The real purpose of this thread is to ask the following picky questions: I am steadfastly refusing to get excited about @file! until all questions are fully resolved. Hand waving will not do. > Question 1: Exactly what will the bzr repository contain? This is the easier question. Indeed, if we focus on the case 3 (some, but not all people use Leo), the answer is clear: the repository will contain the public files in their usual places, and the private files in some inconspicuous place, where most people won't notice. This is a significant change from the leo-editor repository. At present, the files in leo/core and leo/plugins are @thin files containing sentinels. In the new scheme, the files in leo/core and leo/plugins will be public files without sentinels. In this regard, the harder question to answer involves case 1 (everyone uses Leo), but we can ignore that case now that we treat it as equivalent to case 3. > Question 2: Exactly how will public and private files be put in sync? This is a much harder question. I've been daydreaming about what the real issues are. Some preliminary thoughts: 1. Each private file will contain timestamp and checksum information about itself and the corresponding public file. By definition, the format of private files can contain anything without offending non-Leo users, so the sky is the limit. It may also turn out to be useful to have a single timestamp/checksum line at the start of *public* files. However, this would be a measure of last resort, as non-Leo users would likely complain loudly. OTOH, all source code control systems have mechanisms for putting time stamps in files automatically, so maybe this would not be too odious to non-Leo users. We can use this information to detect out-of sync conditions. Probably, Leo will use the actual file modification dates (not the cached dates) to determine whether to use the full-blown @shadow update algorithm (the public file is newer) or just use the normal read algorithm (the private file is newer or contemporaneous with the public file). 2. Inspired by Ville's idea of a multi-pass algorithm to implement sentinel padding, I see that there is no need to revise the fundamental @shadow update algorithm to handle changed private-file format. No matter what the private file's format morphs into, a prepass could recreate the old (@thin) format from the new format. Leo would then apply the @shadow update algorithm to the reconstituted @thin-format text. In practice, it is rare to use the @shadow update algorithm, so this should not be a performance concern. Presumably this would be the simpler option. I'm not entirely ruling out changes to the @shadow update algorithm, but it's not something I would do lightly. In contrast, converting new-style private files to old-style private files seems like a straightforward approach. Furthermore, the unit tests involved would seem to be useful in developing the new-style format in the first place. 3. It is still not clear how to simplify the task of committing files in synch. At present, I think that ensuring synchronization when files are committed would be very handy. In contrast, detecting and dealing with out-of-synch files when pulling or merging appears to be asking for trouble. From my experience, it is hopeless to ask any user (including, especially, me) to sort out what to do when a problem arises while reading a .leo file. The user is surprised, confused and not in possession of enough data to make a reasonable choice. Out-of- synch warning dialogs can *never* be a design option. If they are required, the whole scheme fails. Period. 4. Happily, bzr is written in Python, so it is conceivable to hack bzr to aid Leo updates. OTOH, this probably would not be tolerated in non- Leo environments, and may not work so well in cvs and other non-Python source code control systems. In any case, I am willing, at least for now, to consider allowing bzr to help, if only as a thought experiment. As you can see, significant issues remain. This hardly surprises me. The difficulty of synchronizing files reliably is *the* reason* Leo has always used sentinels. Perhaps this will turn out to be an intractible problem, once again. The difference this time, however, is that the problem is being examined in a new context, namely that of bzr in particular and source code control systems in general. And we must not forget the new tools available to Leo: @shadow and @auto. Taken together, the new context and new tools may make possible a reliable solution that was not ever available before. We shall see. This is most definitely an open question. I am hoping for your comments and suggestions. This is an important problem, and it is by no means totally solved at present. 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 -~----------~----~----~----~------~----~------~--~---
