Leo and fossil

[Edward K. Ream]

For several years now, Vitalije and Offray have proposed interesting ideas based on fossil. And they have persisted, politely, for which I am grateful.

At last I see that fossil can be considered a stand-alone resource--it doesn't need to replace git.  It's just a tool. It can be installed in less than a minute with `pip install fossil`.  I have just done so.

So now I am more receptive to these ideas.  I'll comment more in the "Leo's Real Weaknesses" thread when I have more time.

Edward

[vitalije]

On Monday, January 16, 2017 at 11:45:56 AM UTC+1, Edward K. Ream wrote:

So now I am more receptive to these ideas. 

Edward

Glad to hear that. 

[Terry Brown]

On Mon, 16 Jan 2017 04:46:13 -0800 (PST)
vitalije <vita...@gmail.com> wrote:

> On Monday, January 16, 2017 at 11:45:56 AM UTC+1, Edward K. Ream
> wrote:
> >
> > So now I am more receptive to these ideas.

I haven't followed the fossil discussion too closely, but I'd argue
for, rather than adding fossil as a single new data backend, revisiting
and refreshing (or replacing) Leo's capability of using a "DB" backend,
with a view to making it a pluggable layer where you might be plugging
in to fossil or git or sqlite3 or MongoDB etc. etc.

I think we had a working proof of concept use of Zope Object Database
(ZODB) at one point. I'm not sure that's still an interesting target,
but certainly a good place to review.

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

[vitalije]

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)
• it keeps all its data in just one file, while git creates .git subtree

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

[Edward K. Ream]

​​

On Tue, Jan 17, 2017 at 3:09 AM, vitalije <vita...@gmail.com> wrote:

 

The next more challenging task is to create an elegant GUI that user can use to run all those functions.

​...
​

 

I am not sure that all this would be u

​​

seful 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.

​Likely.  A similar problem is presenting options to git's cherry picking.  SourceTree, does a superb job of this.  In fact, iirc, you can always select/cherry-pick the code that you want to add to each commit. SourceTree has (or used to have) severe performance problems, which is why I no longer use it, but its interface is worth careful study.

In short, the interface may determine whether a feature is useful or not.  A "paper" design can be suggestive before coding.  A prototype, if easily done, is the best.

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?

​Who knows, indeed.  This is an important question.

I could have used something like this recently.  ​I did a git -- checkout to revert some files. When I restarted Leo I got a list of "recovered nodes".  I would have liked an easy way of cherry picking the nodes. Alas, none of the "old" nodes could be easily used, because they weren't (and couldn't be) cloned.

Edward

[Terry Brown]

On Tue, 17 Jan 2017 01:09:47 -0800 (PST)
vitalije <vita...@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.

> - 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

[Offray Vladimir Luna Cárdenas]

Hi,

On 17/01/17 09:19, 'Terry Brown' via leo-editor wrote:
> On Tue, 17 Jan 2017 01:09:47 -0800 (PST)
> vitalije <vita...@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
>> subtree
> I'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

[vitalije]

On Tuesday, January 17, 2017 at 3:19:58 PM UTC+1, Terry Brown wrote:

I assume you mean it's just one Python file, that could be distributed
with Leo?  That is an advantage.

Fossil is native application not python script.

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>)

Cheers -Terry

Well, I can easily change my script to provide API that Terry suggested, using fossil.

I'm not sure there's enough difference in convenience there to put a lot
of weight on that distinction.

You are right. It maybe just matter of preference and therefore not so important. IMO, sharing, moving, copying is much faster(=easier) for a single file than for a subfolder.

As I have seen in links that you pointed to, you have done some node versioning before. I didn't study it very thoroughly so I maybe very wrong, but I feel that you had some unnecessary difficulties with the UNLs, so you encoded them into base64. In my outline encoding scheme, I believe those problems are voided.

Vitalije

[Terry Brown]

Can't watch the youtubes right now. I suspect google will tell you how
to do most of queries listed on [4] in git too. And I'm not sure how
relevant they'd be to Leo node level versioning, given the need to
address nodes rather than files. And the desire to have the node
history interaction interface in Leo itself. Certainly Fossil's local
web server approach is neat in terms of providing a richer reporting
interface than git as standard.

I think there's a two birds with one stone opportunity here if the
development proceeds with a generic interface to multiple backends, of
which Fossil could be one. I'm thinking not so much of git but a
server based DB like Mongo or Postgres or MySQL ... suddenly
collaborative Leo outline editing is a big step closer.

Cheers -Terry

[Offray Vladimir Luna Cárdenas]

Hi,

On 17/01/17 11:00, 'Terry Brown' via leo-editor wrote:
>
> I think there's a two birds with one stone opportunity here if the
> development proceeds with a generic interface to multiple backends, of
> which Fossil could be one. I'm thinking not so much of git but a
> server based DB like Mongo or Postgres or MySQL ... suddenly
> collaborative Leo outline editing is a big step closer.
>
> Cheers -Terry

You have a distributed server based DB for collaborative editing already
with fossil, with and integrated pwoerful query and programming language
and almost no requirements for installation. That's why my explorations
started there. There is, still, road ahead, and my own explorations
could not suit Leo's approach, but the crosspollination of ideas surely
will be a big win.

Cheers,

Offray

[Kent Tenney]

from a couple years ago, I'm as convinced as ever this is what

I want for a dev environment, instant access to versions of node

content which are 'next' to each other, not before and after.

##################################################
OK, I've written a simple implementation of 'spatial versioning'

A database maintains a table 'choices' with 3 columns:
- id (node gnx)
- index (currently selected choice)
- data (a json dict with numeric keys, the value a dict {'h':p.h, 'b':p.b})

The gui element turns out to be not required, in fact, I expect
it would be horrible to have tabs for each choice.

I have 2 buttons: 'right' and 'left'

clicking 'right' increments the index and pulls headline and body from the db,
making a copy of the current node h&b if it's a new index

clicking 'left' decrements the index ...

The Leo file knows nothing about any of this.

A plugin sets up db access and provides one function:
update_choice(p, offset):

p is the current position, offset is 1 or -1

There is lots of room for enhancement, but it already looks to
offer what I've been wanting: access to ad-hoc 'what if' scenarios
instead of the more formal 'and then' world view of VCS.

Thanks,
Kent
##################################################

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+unsubscribe@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Tue, Jan 17, 2017 at 9:32 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

​​

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 have copied these links and watch them soon.

As just mentioned in another thread, fossil stuff will likely happen later this year.  That is, I personally have higher priority work.

I would encourage everyone interested in fossil to continue their work, even as I work on other things.  And later, if I seem to forget fossil, please remind me ;-)

Edward

[john lunzer]

Been mostly on the sidelines on this one, mostly because I didn't have time to think about it. 

I think node versioning is a potentially "killer app". Having a fully automatic document versioning system at the .leo file level and node level would be a turbo boost in project organization and development tracking, a fine-grained full-fledged document history. At this level you could truly be able to see a piece of software unfold and develop in ways that aren't foreseeable with manual operation. I think it would also provide robustness to the concept of "undo". Being able to "undo" node level edits at any time and location is an awesome idea. There are potential statistical and visualization concepts that can aid development as well.

I'm going to have to agree with Terry. In this context Fossil is a backend. The concepts of document/node versioning need to be abstracted to fit Leo and then a backend can be plugged into what Leo is trying to accomplish.

[Edward K. Ream]

On Mon, Jan 23, 2017 at 12:39 PM, john lunzer <lun...@gmail.com> wrote:

I think node versioning is a potentially "killer app".

​Maybe.  I recently used gitk <filename> to review seemingly mysterious changes to a single file.  Not "killer", by any means, but useful enough.
​

 

Having a fully automatic document versioning system at the .leo file level and node level would be a turbo boost in project organization and development tracking, a fine-grained full-fledged document history. At this level you could truly be able to see a piece of software unfold and develop in ways that aren't foreseeable with manual operation.

​I am skeptical about such grand claims. The real "action" consists of ideas.  They get translated into a gazillion small steps.  It's almost certainly impossible to go backwards from code to concept.  My present opinion, lightly held, is that if you can't deduce what is happening from the checkin logs, you have no chance of doing so from the actual code.
​

 

I think it would also provide robustness to the concept of "undo". Being able to "undo" node level edits at any time and location is an awesome idea. There are potential statistical and visualization concepts that can aid development as well.

​Again, I am skeptical.  I suppose I could be persuaded by nifty visualizations.

Edward

[john lunzer]

Well, if I'm being honest this is all theoretical in my mind. I've been looking into Fossil more and just the name triggers ideas. Fossil was chosen as a name due to the fact that all artifacts in Fossil are immutable and could be thought of as fossils. The imagery of archaeology is what I find powerful. 

An automatic and "fossilized" undo system can be useful, here is an anecdote. I was recently working on some code that was not version controlled (I know, I was asking for it) and I accidentally deleted a node containing a class implementation that I didn't realize was gone until hours worth of coding later, I wasn't hitting that part of the code in my testing of other parts of the program. After realizing my mistake, some private expletives and near cardiac arrest I saved my file's subtree to another .leo file and spent the next half hour undoing every edit I had made until I got to when I deleted the class. Luckily I'm in the habit of rarely ever closing Leo and I was thanking my lucky stars that Leo has what seemed to be an unlimited undo history.

An edge case to be sure, but it showed me how powerful it would be to copy the last known edit of a node named "class Panel". I learned a powerful lesson about the value of version control. So, if version control is so important and outlining is so powerful, then why wouldn't version control at the node level be powerfully important? Putting aside logical silliness I think the question has merit.

This statement of yours got me thinking:

​I am skeptical about such grand claims. The real "action" consists of ideas.  They get translated into a gazillion small steps.  It's almost certainly impossible to go backwards from code to concept.  My present opinion, lightly held, is that if you can't deduce what is happening from the checkin logs, you have no chance of doing so from the actual code.

Keeping on the theme of archaeology, when an archaeologist finds an artifact and learns something from it what are the chances that an individual meant for that artifact to be found and meant for it to result in learning. My guess is almost never. Extend this to programmers and version control. What you see in a version control repository is only what the programmer intends for you to see, a gazillion small steps lost to time, never to be uncovered. Well designed and well manicured code can be instructive and it is primarily how we are presented with code in the modern era. 

People like you, Edward, are about as active a committer as I have met, most projects on github come nowhere near to your level of individual activity. You're doing it the "right" way but I don't think we can expect everyone to do it the right way. And even for you, we've still missed a gazillion of your small steps. Archeologically speaking are we to believe that we have nothing to learn from those small steps. My theory is that there has to be something there.

Here is a basic idea, and one that comes from data science and statistics. When you've got a gazillion of something usually the only way to digest it is with statistical data. Numbers and figures which help describe the nature and shape of that big blob on gazillion somethings. 

Let's take for example edits about a gazillion code edits between two major versions of software. If I'm trying to learn about this code I can go back through the version control logs, which may contain any number of commits. Combine that with a "change log" and I think it's fair to say I could deduce which files and features received the most attention. I can then study the code in question. But what if it was possible to create a much more detailed map of how code develops? What if I could say with a few lines of statistics and some visualization that 90% of the edits were confined to this 10% of the code?

To me being able to say that feels important. I don't know if it actually is. From the side of the primary/current developers I think it could be a useful tool to help you analyze and track your own code. It might help you focus your documentation efforts. From the point of view of new developers or people studying you code it might help them identify important areas of the code.

Sorry for the long post. This is not really a Leo only concept. I only meant to lay it out because I believe that because of Leo's nature as an outlining editor an implementation of "automatic node level version control" would be the most powerful and potentially most useful for Leo, where it would be pretty easy to gather the statistics and pinpoint smaller portions of code. 

[Edward K. Ream]

​​

​On Mon, Jan 23, 2017 at 2:55 PM, john lunzer <lun...@gmail.com> wrote:

Well, if I'm being honest this is all theoretical in my mind. I've been looking into Fossil more and just the name triggers ideas. Fossil was chosen as a name due to the fact that all artifacts in Fossil are immutable and could be thought of as fossils. The imagery of archaeology is what I find powerful. 

An automatic and "fossilized" undo system can be useful, here is an anecdote. I was recently working on some code that was not version controlled (I know, I was asking for it) and I accidentally deleted a node containing a class implementation that I didn't realize was gone until hours worth of coding later,

​As you imply, the solution is to use git, or any other sccs. I think that's the end of the story.
​

 

So, if version control is so important and outlining is so powerful, then why wouldn't version control at the node l

​​

evel be powerfully important?

​I don't follow the argument.  In your case, you deleted a node.  How could you then Leo to recover that node using node history?

​I am skeptical about such grand claims. The real "action" consists of ideas.  They get translated into a gazillion small steps.  It's almost certainly impossible to go backwards from code to concept.  My present opinion, lightly held, is that if you can't deduce what is happening from the checkin logs, you have no chance of doing so from the actual code.

​...

People like you, Edward, are about as active a committer as I have met, most projects on github come nowhere near to your level of individual activity. You're doing it the "right" way but I don't think we can expect everyone to do it the right way. And even for you, we've still missed a gazillion of your small steps. Archeologically speaking are we to believe that we have nothing to learn from those small steps. My theory is that there has to be something there.

​It's an interesting question. Sure, there may be something to be learned from looking a gazillion small steps.  But life is way too short for such an approach.

Let's consider a real-world example, #334: simplify (rewrite) Leo's importers. This issue is part of my distributed engineering notebook.  When I was finished, I created official documentation.

Devs should study both the git issue and the official docs closely. It would be a huge waste of time to study the git commits or (oh horror!) the git diffs.

Really, I think you should abandon the archeological approach.  Why go through Henry Kissinger's garbage?  You don't even need to file a Freedom of Information request to get the full scoop :-)

Here is a basic idea, and one that comes from data science and statistics. When you've got a gazillion of something usually the only way to digest it is with statistical data. Numbers and figures which help describe the nature and shape of that big blob on gazillion somethings.

​There is no doubt that deep learning is going to transform the world.  But if the intentions and notes for a project already exist, there is no need to recreate them.

Edward

[john lunzer]

I don't follow the argument.  In your case, you deleted a node.  How could you then Leo to recover that node using node history?

 

The parent node's history would contain the deleted node. The concept of node level version control is the marrying of an outlining editor with version control at the node/edit level. When combined you get a rich history and a robust "undo" mechanism. In this edge case it is robust "undo" I was after.

I will emphasize one thing you stated:

​There is no doubt that deep learning is going to transform the world.  But if the intentions and notes for a project already exist, there is no need to recreate them.

You've exposed the illusion that begs for the archaeological approach to be investigated. However perfect a programmer thinks they are they are still human and will still unknowingly misrepresent their intentions and their work. And they will do this with a frequency that negatively impacts their work and their relationships. As humans this is what we do, we're experts at it. If we didn't the world would be more orderly and less contentious place, but also likely less gratifying. The archaeological approach is intended to help the code author better understand his own work and more effectively represent their work to the world. It is also intended to help the code readership more easily digest of others. 

It's an interesting question. Sure, there may be something to be learned from looking a gazillion small steps.  But life is way too short for such an approach.

This is only true if you think we would need something as involved as "deep learning" to gain insight from what is a pretty straight forward data. In my professional life I am an "image scientist", which is roughly one part data scientist, one part software engineer, one part image analyst. There are always rumblings of "deep learning" and "machine learning" but in reality the required insight into most datasets can be extracted using simple statistics (mean, median, standard devitation). Complex problems can benefit from "deep learning" but trust me in saying, "we're not there yet".

Devs should study both the git issue and the official docs closely. It would be a huge waste of time to study the git commits or (oh horror!) the git diffs.

Sir, I am not insane. I, being human, must have misrepresented my intentions. I agree that it would be a huge waste of time to manually study git commits and git diffs. However, the archaeological approach would likely involve an algorithm gathering statistics from commits and diffs.

My closing argument here is that I think you're overestimating the skill of the programmer and you're underestimating the value of what you call "garbage". I'd warn against both of those outlooks, they will only serve to blind you from a truth potentially hiding right under your feet. A truth that could have the power to transform the way you work. That said, I'm truly not trying to affect your focus, I think your current priorities are good. 

[Offray Vladimir Luna Cárdenas]

Hi,

Core object provides outlining with node versioning:

http://coreobject.org/

Still on early stages, but I think that it helps into making a point about these possibilities (which doesn't mean that they should be implemented on Leo ;-) ).

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+...@googlegroups.com.

[john lunzer]

Nice, pretty much what I imagined it would look like. Now that I think about it statistical analysis of nodes can be done completely separately from node history. Just need to track each edit with a timestamp.

[Offray Vladimir Luna Cárdenas]

On 25/01/17 19:56, john lunzer wrote:
> Nice, pretty much what I imagined it would look like. Now that I think about it statistical analysis of nodes can be done completely separately from node history. Just need to track each edit with a timestamp.
>

With Core Object (alike) technologies you add a temporal dimension to
the spacial dimension of outlines/trees. I think that these are
interesting ideas (despite of not having plans to implement them soon
for my outliner). As I said I'm now more focused on history at file
level instead of node level and a smooth user experience of literate
computing in an outliner environment, which is still a long path to
follow, but once this is done, collaborative real time outline editing
with node history would be an interesting pursue.

Cheers,

Offray

[john lunzer]

What really excites me about this concept is getting "version control for free". 

Starting out at the file level sounds good. The question is what level of granularity: Edit level (like an undo history), save level (changes "committed" every time you save), time interval ("commits" after 2 minutes of inactivity and every 10 minutes if inactivity save not triggered, like an autosave), or completely manual (like a regular SCM).

I like the idea of a combination of a save level and a time interval level. At the save level I'd have a way to include a "commit message" with the save. It would be nice if it were easy to see a summary report between any two commits, sort of like what you see when you do a git pull, which shows a list of files which have been changed and their +/- edits. This is sort of assuming that an outline has multiple @<file> nodes in it. 

I'm not advocating much more than an SCM fully integrated into the outlining software (which is why I'm using common SCM terminology). The difference between this and say what Edward does already is that this would be fully automatic and by default local (in the context of Leo, potentially fully integrated in the .leo file itself). Additionally I'd make it as back end agnostic. The user would have the option to "connect" their .leo file to a hosted/external repository. If you only included the save level commits with custom commit messages I imagine the commit history would look almost exactly like what is seen in the Leo's current git repo. I imagine a smoother workflow by not having to leave Leo. That is how I get to "version control for free".

Fossil seems like a good fit for a back-end because it is self-contained (a single smallish binary, truly cross-platform), uses a single file (easy to keep track of). Mercurial might also make a good back-end because it is more popular and because it's written partially in Python. Then obviously Git has the most popularity, so that is a strong consideration.