On Thu, Feb 11, 2010 at 9:28 PM, sascha <[email protected]> wrote:
> from my experience I see no way to make use of clones in leo in > any professional environment unless I use @shadow. It's your choice, and a common one. It's not the only choice. > Well from this point of view @file seems to be a bit deprecated, > but it is still the standard way to import any file. At present, @file == @thin. >> > While it might not be obvious, this separation causes some significant >> > inconveniences if not problems: These problems are obvious, at least to me. > Well my proposal might incur some dangers, but clustering all private > files in one file (or leo itself) does not hint at backup at all. I take it that this is the heart of your proposal. >> > So with respect to making leo a mainstream editor, at least for me this >> > raises the question, whether leo would be better of, if we remove @file, >> > @thin, @nosent and instead rename @shadow to @file. This is just a matter of terminology. The real question is, how useful is @shadow in cooperative environments? The answer is clear enough: @shadow works well as long as you are the only person using Leo. If more than one person is using Leo, then @thin is, by far, the best solution. The big problem is, what happens when a) several people want to use Leo on a project but b) managers or other co-workers object to using @thin files. Imo, this problem is hard, but not very interesting. @thin is the proper *technical* solution. If people can't use that, then @nosent, @auto or @shadow are all workarounds with different characteristics. > So maybe the central target for collaboration should be, to provide > annotation files (providing views) together with (possibly changed) normal > external files. An interesting idea. Bzr scripts might provide such files. Presumably bzr scripts could ensure synchronization between public and private files in the repository. > This could provide a very promising workflow for collaboration > usecases. > If I want to connect to a leo based workflow, there is no need for > some sort of skeleton .leo file. > Instead I could just grab one or more exported views (either from some > sort of repository or freshly exported > from colleagues) and import them into my empty .leo file (this way I > could even incrementally expand my view of > the complete project, by incrementally adding more an more views). > In this case the imported views would trigger two things: > 1. One or more view nodes (probably containing lots of (cloned) > subnodes) will be added to the current .leo. > 2. Missing files will be automatically imported. It seems as if you are saying that the (bzr,git,hg) repository is, in essence, the .leo file. This is an interesting thought. Alas, the same people who object to sentinels will likely object to Leonine data in in the repository. > The second point will also provide the possibility, to give every view > node an ID that will be valid across .leo files! Gnx's already do this. But so does bzr,git,hg. > All in all this change of perspective turns the current situation > upside down, i.e. instead of requiring every user to > cope with sentinels and figure the optimal file type, just to ensure > that a few groups of lucky leo only users can > collaborate, we could ban sentinels completely and just require, that > those leo users who do collaborate export additional > infos for this purpose. This is an old idea, imo. Synchronization problems will kill it, unless this idea is combined with bzr scripts or other measures. Let me summarize briefly: 1. Hardly anybody reads long posts, myself included. I often write long posts myself, but mostly to clarify my thinking, and to provide a permanent record of thoughts. I should have remembered this when writing my 42 post :-) I'll have to reduce it to a haiku. 2. Imo, no scheme that requires synchronizing data has any chance of working, except: 3. It might be fruitful to imagine an bzr repository itself to be an analog of a .leo file. I'll let this percolate in the back of my mind, but I'm not overly excited about it. @thin is the best, simplest solution. Everything else will be a more complex workaround. 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.
