On Mon, Jan 23, 2012 at 9:33 AM, HansBKK <[email protected]> wrote: > On Monday, January 23, 2012 3:25:21 PM UTC+7, Differance wrote: >> >> > To me, the main topic - preventing data loss due to multi-file clones. >> >> :-) I'm developing the original topic -- why Edward likes clones. >> >> This I don't get. I haven't said anything about safety enforcement, >> first. If you're talking about clone wars, all I've said is that >> clearing up functions (code maintenance/having leo maintain single >> unitary files vs. templating) should help make things clearer for >> clone wars, not that it would necessarily make things safer. > > > Ah, sorry, my lizard-brain filtering things a bit too much - yes I was > focusing on clone-wars. > >> >> Why/what are you doing in your use case that calls for adding one clone to >> the master source @file branches? You've described the master source files, >> and your hybrid things which would be under @template branches. But I don't >> see what you're doing that you want to put clones under @file branches. > > Aha, this may be the cause of some misunderstanding - remember since Leo > went through the "one node" change, there is not internal distinction > between any "original" or "master" instance, as far as the software is > concerned they are all exactly the same node, just appearing under multiple > parents. > > I'm not "putting" clones there, but since they are exactly the same nodes as > the other instances in my "templating branches" they are nonetheless clones > - I certainly don't want them to be disconnected copies.
It seems to me that you're emulating what I'm recommending, only I have a functional definition of the single clone @file -- it's for one unitary external file, not any hybrid external file. If the distinction in functions I'm describing were implemented, you'd have what you're trying to do and it would be an aspect of the app that users would grasp based on the difference in function. >> > Your @template directives would need to allow for external modification >> > (two-way import/export) as well, so my confusion is to how this concept in >> > and of itself would simplify or make safer things regarding clone wars, as >> > the fundamental problem would IMO remain. >> Chiefly it would separate two different functions. But it wouldn't make >> things safer in and of itself. Trying to both do code maintenance and do >> templating in the same kind of @ branch strikes me as a recipe for confusion >> either in development or usage. Separating them should make it easier to >> conceptualize how to handle external modification if only by handling two >> types of external files distinctly. > > This part of our misunderstanding comes from your use of the term "code > maintenance", when that doesn't mean anything to me in terms of Leo's > functionality (and in fact I'm not actually maintaining any code with Leo > anyway. My interpretation of what you mean by this is something like > "keeping external files intact" and therefore (I think) corresponds to my > term "master source files". > >> But what your example case I don't get, plus what you're speaking of as >> "the fundamental problem." If you're talking about data safety/preventing >> data loss due to multi-file clones I'm not clear how your example relates to >> that. > > Yes, that is what I'm talking about - clone wars, data loss due to > multi-file cloning. And (my interpretation of) the fundamental cause of that > problem is having nodes cloned within multiple @ <file> branches where the > possibility exists of that single node's data getting out of sync in > multiple external files. My "SOP" solution is to ensure that Leo is only > able to import from one of those external files, because my brain isn't able > to remember/keep track where it is OK for me to edit and where not. Some of the difference comes from the fact I was not starting from the specific problem that a cloned node's data would be in multiple external files that could be independently modified outside Leo. I don't know how you do things so you ensure Leo only imports from one of those external files, but my concept would turn it into a situation where it naturally follows that the "source" @file file's version of the node would override any such revisions in the various hybrid files that use that same node. Users who modify a hybrid @template file are always subject to being overridden automatically that way, and it stands to reason that they would. Thus Leo just plays the role of updating all dependent hybrid @template files to match the definitive information in the source @file file. Seth > I now understand that your @template idea was not intended in and of itself > to directly address this problem, and therefore the fact that I don't > understand how it's supposed to work no longer matters (to me). > > Thanks a lot for your patience, and my apologies to the extent I've wasted > your time and list bandwidth. . . -- 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.
