Discussion:
Leo and fossil
(too old to reply)
Edward K. Ream
2017-01-16 10:45:56 UTC
Permalink
For several years now, Vitalije and Offray have proposed interesting ideas
based on fossil <http://fossil-scm.org/>. 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
<https://groups.google.com/forum/#!topic/leo-editor/19288wA3aKA>" thread
when I have more time.

Edward
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
vitalije
2017-01-16 12:46:13 UTC
Permalink
Post by Edward K. Ream
So now I am more receptive to these ideas.
Edward
Glad to hear that.
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
'Terry Brown' via leo-editor
2017-01-16 16:25:20 UTC
Permalink
On Mon, 16 Jan 2017 04:46:13 -0800 (PST)
Post by vitalije
Post by Edward K. Ream
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
Post by vitalije
Post by Edward K. Ream
Edward
Glad to hear that.
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
vitalije
2017-01-17 09:09:47 UTC
Permalink
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
Post by 'Terry Brown' via leo-editor
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@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
2017-01-17 10:42:38 UTC
Permalink
​​
Post by vitalije
The next more challenging task is to create an elegant GUI that user can
use to run all those functions.
​...
​
Post by vitalije
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
Post by vitalije
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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
'Terry Brown' via leo-editor
2017-01-17 14:19:55 UTC
Permalink
On Tue, 17 Jan 2017 01:09:47 -0800 (PST)
Post by 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
- 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.
Post by vitalije
- 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
Post by vitalije
Post by 'Terry Brown' via leo-editor
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Offray Vladimir Luna Cárdenas
2017-01-17 15:32:18 UTC
Permalink
Hi,
Post by 'Terry Brown' via leo-editor
On Tue, 17 Jan 2017 01:09:47 -0800 (PST)
Post by 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
- 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
Post by 'Terry Brown' via leo-editor
Post by vitalije
- 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]

[3]

[4] http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md
Post by 'Terry Brown' via leo-editor
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+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
'Terry Brown' via leo-editor
2017-01-17 16:00:01 UTC
Permalink
On Tue, 17 Jan 2017 10:32:18 -0500
Post by Offray Vladimir Luna Cárdenas
Hi,
Post by 'Terry Brown' via leo-editor
On Tue, 17 Jan 2017 01:09:47 -0800 (PST)
Post by 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
- 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
Post by 'Terry Brown' via leo-editor
Post by vitalije
- 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]
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
Post by Offray Vladimir Luna Cárdenas
[2] http://youtu.be/8y_ABXwYtuc
[3] http://youtu.be/ghtpJnrdgbo
[4] http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md
Post by 'Terry Brown' via leo-editor
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+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Offray Vladimir Luna Cárdenas
2017-01-17 16:04:53 UTC
Permalink
Hi,
Post by 'Terry Brown' via leo-editor
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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Kent Tenney
2017-01-17 16:33:12 UTC
Permalink
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
##################################################


On Tue, Jan 17, 2017 at 10:04 AM, Offray Vladimir Luna Cárdenas <
Post by Offray Vladimir Luna Cárdenas
Hi,
Post by 'Terry Brown' via leo-editor
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
--
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
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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.
To post to this group, send email to leo-***@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
2017-01-21 23:11:27 UTC
Permalink
On Tue, Jan 17, 2017 at 9:32 AM, Offray Vladimir Luna Cárdenas <
***@riseup.net> wrote:

​​
Post by Offray Vladimir Luna Cárdenas
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] http://youtu.be/8y_ABXwYtuc
[3] http://youtu.be/ghtpJnrdgbo
[4] http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md
Post by 'Terry Brown' via leo-editor
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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2017-01-23 18:39:42 UTC
Permalink
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.
Post by Edward K. Ream
On Tue, Jan 17, 2017 at 9:32 AM, Offray Vladimir Luna Cárdenas <
​​
Post by Offray Vladimir Luna Cárdenas
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] http://youtu.be/8y_ABXwYtuc
[3] http://youtu.be/ghtpJnrdgbo
[4] http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md
Post by 'Terry Brown' via leo-editor
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
--
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.
To post to this group, send email to leo-***@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
2017-01-23 19:48:20 UTC
Permalink
On Mon, Jan 23, 2017 at 12:39 PM, john lunzer <***@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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2017-01-23 20:55:18 UTC
Permalink
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.
Post by Edward K. Ream
​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.
--
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.
To post to this group, send email to leo-***@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
2017-01-24 08:36:08 UTC
Permalink
​​
​On Mon, Jan 23, 2017 at 2:55 PM, john lunzer <***@gmail.com> wrote:

Well, if I'm being honest this is all theoretical in my mind. I've been
Post by john lunzer
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.
​
Post by john lunzer
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
Post by john lunzer
Post by Edward K. Ream
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
<https://github.com/leo-editor/leo-editor/issues/334>: simplify (rewrite)
Leo's importers. This issue is part of my distributed engineering
notebook. When I was finished, I created official documentation
<https://github.com/leo-editor/leo-editor/blob/master/leo/doc/importers.md>.


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.
Post by john lunzer
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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2017-01-24 13:39:53 UTC
Permalink
Post by Edward K. Ream
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.
Post by Edward K. Ream
​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
Post by Edward K. Ream
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
Post by Edward K. Ream
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.
Post by Edward K. Ream
​​
Well, if I'm being honest this is all theoretical in my mind. I've been
Post by john lunzer
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.
​
Post by john lunzer
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
Post by john lunzer
Post by Edward K. Ream
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
<https://github.com/leo-editor/leo-editor/issues/334>: simplify (rewrite)
Leo's importers. This issue is part of my distributed engineering
notebook. When I was finished, I created official documentation
<https://github.com/leo-editor/leo-editor/blob/master/leo/doc/importers.md>.
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.
Post by john lunzer
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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Offray Vladimir Luna Cárdenas
2017-01-25 21:33:21 UTC
Permalink
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
Post by 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.
On Tue, Jan 17, 2017 at 9:32 AM, Offray Vladimir Luna Cárdenas
​​
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] http://youtu.be/8y_ABXwYtuc
http://youtu.be/8y_ABXwYtuc
[3] http://youtu.be/ghtpJnrdgbo
http://youtu.be/ghtpJnrdgbo
[4]
http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md
<http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md>
https://groups.google.com/d/msg/leo-editor/LIUGtgP8T_s/oSQD4RQGeogJ
<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
--
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
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2017-01-26 00:56:23 UTC
Permalink
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.
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Offray Vladimir Luna Cárdenas
2017-01-26 16:29:57 UTC
Permalink
Post by 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.
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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2017-01-26 17:33:20 UTC
Permalink
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.

On Thursday, January 26, 2017 at 11:30:00 AM UTC-5, Offray Vladimir Luna
Post by john lunzer
Post by 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.
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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
vitalije
2017-01-17 15:59:35 UTC
Permalink
Post by 'Terry Brown' via leo-editor
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
Post by 'Terry Brown' via leo-editor
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
--
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.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Continue reading on narkive:
Loading...