On Mon, Jan 23, 2017 at 2:55 PM, john lunzer <[email protected]> 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 <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. > 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 [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.
