On Tue, Oct 11, 2011 at 10:51 PM, Offray Vladimir Luna Cárdenas > This kind of connection between a portable and minimalist SCM/VCS and Leo is > what I'm trying to communicate about the bridge between Leo and Fossil.
Thanks for these comments. Imo, undo is an extremely hard problem, for several reasons: 1. There is a complex interaction between global undo and per-node undo. Leo's present (too-complex) undo code relies on undo and redo operations being done in strict order. I don't see, offhand, how to support per-node undo and keep global undo consistent. Perhaps I am being too timid... 2. The real challenge, however, is being able to predict what undo will do, when there are a lot of possibilities. Bzr's qlog and qdiff commands do an excellent job of providing an overview of the changes made by commits. However, I wouldn't want to base undo on them: the detail provided by a qdiff of a single file can be overwhelming, and of course it's all text based. At the minimum, we would need something as useful as Leo's "Recovered nodes" tree. Without this node orientation, I would be totally unable to use diffs. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
