Hi,
On 17/01/17 09:19, 'Terry Brown' via leo-editor wrote:
On Tue, 17 Jan 2017 01:09:47 -0800 (PST) vitalije <vitali...@gmail.com> 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.
No. Is not a Python file. Fossil is distributed like a small binary available in all Leo platforms [1] and "installing" it, is just copying.
[1] http://fossil-scm.org/index.html/uv/download.html
- it keeps all its data in just one file, while git creates .git subtreeI'm not sure there's enough difference in convenience there to put a lot of weight on that distinction.
Richard Hipp, Fossil and SQLite author, makes that distinction and about the "pile of files" database (like the .git folder) instead of the single file approach[2]. There is a lot of querying capabilities of the last one, as you can see on [4]
[2] https://www.youtube.com/watch?v=8y_ABXwYtuc [3] https://www.youtube.com/watch?v=ghtpJnrdgbo [4] http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md
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.
I agree with Vitalije about using fossil at file level, instead of node level and my (Grafoscopio) experiments went in the same direction. I remember thinking, years ago, that all the complications about working with external files and external editions could be solved by an integrated simple DVCS (fossil) and a simpler file format (Yaml) that were coupled with Leo (as pointed in the 2011 "Leo new directions" thread). By making my own prototypes, I can now express better that intentions.
That doesn't mean that Leo can not talk with external DVCS, but having the power of one simpler format and DVCS to express how (internal or external) files in a project change, including .leo files should be part of a smooth experience about representing projects and their history. I would start for this smooth integrated experience and, after that, I would start to abstract and decouple to make it neutral to the DVCS backend.
Cheers, Offray -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
