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. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
