WOW. Just no more comments needed.
Nevertheless, after playing a little with this new feature (which really adds a lot of value to checkpoints which I hadn't previously used), and just as brainstorming ideas, I would like to post some possible "improvements" (unless proved absolutely pointless):
Currently we have a list of checkpoints which are just "virtual" copies (containers) of the book in different stages of modification (or not). And the last one (or the only one if no checkpoint has been explicitly created) is just an "unnamed" one.
So imagine you have "1" - "2" - "3" - "Unnamed" as your 4 checkpoints in the editing session. When you "revert" to "2", you are just changing the container you are working with. You just jump from "Unnamed" to "2".
The first problem / possible enhancement is that when you continue working in "2" you lose your original version of "2". And maybe you made that "2" checkpoint because of whatever
critical/special/important reason, so you don't want to lose the snapshot that "2" actually is.
So I propose the next modification. When you jump to "2" what you would get would be: "1" - "2" - "unnamed" (copy of "2" and current container) - "3" - "unnamed". In this way you would never lose the original checkpoint state when reverting to it, even if you start editing.
The second enhancement. This proposed scheme has a serious trouble if you start jumping between checkpoints: a lot of "unnamed" ones are going to be created. So what we need is the next procedure: when I jump from one checkpoint
which is not named to any other I must check if that origin checkpoint is actually different (or not) from its precedent (and parent) one. If it is the same, then just delete it.
So in the previous example, if I had just made "3" and then I have just jumped from the last "unnamed" one I would have ended with just "1" - "2" - "unnamed" (copy of 2 and current container) - "3". The last one would have been automatically deleted. If I jumped back to "3" without making any changes I would return to the starting situation (an "unnamed"-child would be created from "3" and the "2"'s child would be killed).
Third enhancement. Do not lose "branches". If you jump to "2" from the 4th "unnamed" and you start editing you are actually "branching" your work. "2" is no longer in the same "working path" of "3" and "unnamed" (unless you repeat the exact same edit actions...)
But curiously, if you create a new checkpoint from "2", that very same "2", and "3" and "unnamed" in addition, are deleted, as if trying cut off the branches...
Of course Calibre cannot be a full fledged version control system, (wait, maybe with Kovid it can, but that's another story...
), but nevertheless I think that with the powerful diff tool you offer there's no problem on keeping "pseudo-branches".
If possible I would do the following: inserting checkpoints in the queue.
Remember that I have proposed cloning "2" in order to keep it safe. So when you revert to "2" you would have "1" - "2" - "unnamed" (copy of 2 and current container) - "3" - "unnamed".
When I start working in the clone of "2" and then I create a new "2.1" checkpoint I propose having "1" - "2" - "2.1" - "unnamed" (copy of 2.1 and current container) - "3" - "unnamed", where "2.1" and its "unnamed" is actually a different branch than "3" and its "unnamed".
Fourth enhancement. A nearly must because of branches: timestamps and delete checkpoint action. As the queue of checkpoints can become really "messy" if there is a lot of branching, (although with the diff you can always compare them so it's messy in structure but not in browsing their contents), I really think that offering a timestamp in the checkpoint list viewer can be really helpful as it can guide the user about when and how they have been created.
And of course a "delete" checkpoint action would be really necessary...
What do you think about these ideas?
I was considering even trying to code them but maybe they are just too much for me...