On Tue, 17 Jan 2017 01:09:47 -0800 (PST) vitalije <[email protected]> wrote:
> Database is just a part of fossil. It isn't question of where Leo can > keep its data. It's about keeping a history of data. Fossil keeps (in > efficient way) all versions of the data, it can show the diffs in > several formats, ... pretty much all that git does. The advantage of > using fossil instead of git, IMHO, is that: > > - it doesn't need to be installed (it is just one executable file, > available for all platforms that Leo supports) I assume you mean it's just one Python file, that could be distributed with Leo? That is an advantage. > - it keeps all its data in just one file, while git creates .git > subtree I'm not sure there's enough difference in convenience there to put a lot of weight on that distinction. If the emphasis is on node versioning, there's this: https://groups.google.com/d/msg/leo-editor/LIUGtgP8T_s/oSQD4RQGeogJ which points to a couple of older posts. I still think this node versioning / node storage should be approached generically with Fossil as an example backend rather than hard coding directly for Fossil. Seems the API would boil down to something like backend.snapshot_node(<node_id>, <node_content>) backend.node_versions(<node_id>) # list version_ids of available versions backend.get_node(<node_id>, <version_id>) with some details maybe re search by headline etc. Cheers -Terry > On Monday, January 16, 2017 at 5:25:22 PM UTC+1, Terry Brown wrote: > > > > Another question is whether the integration is just at the > > load/save level or at the node traversal level, i.e. constantly > > using a data backend. I think if we started with the load/save > > level, the sweet spot might be some subtree / node level live > > refresh from a data backend. > > > > For diffs, seems an xml to yaml conversion would achieve that? > > Like I say, haven't been following the conversation too closely. > > > > Cheers -Terry > > > > I don't expect integration to be at node traversal level. At the > > load/save > phase (or even on an explicit user request), fossil would record the > new version of the outline. Later, a user might want to see how and > when some node has changed, or what was it like in some earlier > version. The simple script I made for the experiment already enables > all that functionality. The next more challenging task is to create > an elegant GUI that user can use to run all those functions. > I haven't programed in PyQt for a long time. Many things I used to > know I forgot and there seem to be a lot of changes in PyQt since. > Nevertheless, I can imagine how GUI might be like. For example, > imagine a small slider widget along the bottom of body, or in status > line, that represents time. User can slide it left or right and the > selected body would change accordingly as it was at the selected > moment. When focused slider would enable user to switch to the > previous/next version using the arrow keys. > > I am not sure that all this would be useful at all. I can't recall > when was the last time that I needed something like this. But maybe I > would use it more often if it was possible in the first place. The > way I see it, this can be interpreted as "undo/redo" functionality > but persistent between editing sessions and spread at node levels, > i.e. every node has its own "undo/redo" timeline. It may be useful, > who knows? > > Vitalije > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
