On Fri, Jan 29, 2010 at 4:14 PM, Gil Shwartz <[email protected]> wrote:
>> 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). c is the commander, the "owner" of all the data in the outline. The idea is for the read code to make a guess about about how to resolve data conflicts, but then to save "resolution data" in the commander to allow the user, with the help of a plugin, to make different resolution. > I thought that whenever the read code detects a clone conflict, it > create another clone entity. Another hidden root node? Too complicated. All the read code has to do is save the info about conflicts somewhere. Anywhere will do, but the commander is the logical place. 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. The resolution data will indeed contain gnx's of conflicting nodes, along with all the variants of the data in the battling nodes. > I would say I'm against any solution that would make Leo discard of > file data it reads. Saving the conflicting data for later in the commander should satisfy us both. 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.
