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