> I'm not going to change Leo's data structures, but we can attempt to > solve the problem in much simpler ways.
Always good. > After some thought, I realize the essence of the problem involves only > Leo's read code. There are several possible approaches. > > 1. The simplest thing that could possibly work. When a conflict > happens, presumably in the atFile.read code, Leo will remember the > completing versions in, say, c.conflictingNodesList. Entries will > record the vnode and all the conflicting versions of the text. A > plugin could use an open2 hook to attempt to choose the proper > version, possibly by putting up a dialog. I think this is definitely on the right track (even though I'm not sure what c.xxx is). While a plugin can certainly be used to make conflict decisions, maybe like the ones described earlier in this discussion, Leo would still need to reliably display the exact information read from the external files, and be able to manage that. I thought that whenever the read code detects a clone conflict, it create another clone entity. We can have the clone history if we use ids (gnx) like this <original clone gnx>:<version info>. <version info> can be <user id>.<datetime>.<version>, i.e. very much like the current gnx structure. So, for example, if we started with a single clone entity having gnx Gil.20100124231208.1, and the read code detected two versions, the result will be two clone entities, the first with gnx Gil.20100124231208.1:Gil.20100127231242.1 and the second with Gil.20100124231208.1:Gil.20100127231242.2. These clones can be handled by Leo the same way their are today, and a plugin can offer merge and other functionality. If a version is split from the clone it can have a new simple (regular) gnx. > 2. More complicated, but perhaps more useful. Mark some trees with an > @master directive. Presumably, @master and @all would work together > to provide a *single* external file that contains master copies of > data. It's vital to understand that being a "master" node in this > sense affects only Leo's read logic, and *nothing* else. I would say I'm against any solution that would make Leo discard of file data it reads. This comes from my philosophical view that Leo is a _perosnal_ meta-data structure that is layered over files (typically source code files), and should therefore accurately represent the exact file content at read time and later resolve meta-data structure conflict if there are any. If @master is an explicit instruction by the user that Leo discard of some read content, this is indeed a preferred situation in which a informational notification is enough. I would not force the user to use @master, so it might eliminate some of the conflict if the user logic is strong (e.g. single user development environment), but the rest of the conflicts are still in need to be resolved. > 3. Scripting solutions, within Leo or without (xslt). Always open > ended, but I have no great ideas at present. Not sure about this. > Just the start of some ideas. I wanted to throw this out quickly so > people will realize I'm not as negative on this subject as my initial > words may have implied. > > Edward Gil -- 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.
