DeMinds Version History and Recovery
Version History helps Markdown editing stay reversible as your content changes, so you can return to a better state when needed.
In DeMinds, Version History is not meant to record every small edit. It keeps a few key recovery points for your current working content when you save, reorganize, restore, or reparse Markdown.
1. Why Version History exists
Markdown rarely becomes final in one pass.
You may import a source, reorganize headings, adjust hierarchy, merge sections, add notes, or ask AI to rewrite and summarize parts of the content. Many changes are useful, but sometimes the previous version was clearer.
Version History helps in situations like these:
- You save a change and realize the previous structure worked better
- You restore a version and then want to return to the state before that restore
- You want to keep the current working draft before restoring the Baseline
- You want to protect edited content before reparsing or upgrading the parse result
- You want to review whether AI or bulk cleanup changed the content as expected
It is not a full version control system. It is a lightweight editing safety net: it lets you keep working while still being able to return to a stable state.
2. Quick start
Open Version History from the Markdown workspace. You will see the current content, recent versions, a pinned version, and the Baseline.
The usual flow is simple:
- Open Version History
- Select a version to preview it
- Choose Compare to see how it differs from the current content
- Choose Restore to return to that version
- Choose Pin to keep an important version
If you only need to recover a few paragraphs, compare or copy the version content first. If the whole document should go back, then restore the selected version.
3. What DeMinds keeps
DeMinds Version History is centered on the current working Markdown. You always edit the current content. Historical versions are only for preview, comparison, and restore.
Current content
Current content is the Markdown you are editing. It is also the basis for Preview, export, and Continue Working.
It is the only version that is directly edited.
Recent versions
Recent versions are safety snapshots created before key actions.
DeMinds keeps up to 3 recent versions. When a new one is created, the oldest recent version may be removed.
Recent versions are useful when you need to:
- Go back after saving
- Undo the effect of a restore
- Compare before and after reparsing
- Recover the previous state after the current structure became messy
These are not continuous background autosaves. They are not created for every keystroke.
Pinned version
A pinned version is created by you to keep a state you trust.
The rules are simple:
- Only 1 pinned version is kept
- It is not replaced by recent-version rotation
- Pinning again asks whether to replace it
A pinned version is best for saving a stage that feels good enough. You can keep editing the current content while the pinned version remains as a stable reference.
Baseline
The Baseline is the initial state when content enters DeMinds.
It usually comes from import, parsing, or the first generated Markdown. It helps you see what the content looked like at the beginning.
The Baseline is read-only. It is not part of recent-version rotation and is not replaced by the pinned version.
4. When recent versions are created
DeMinds does not create a history version when you open a document, switch Preview, change font size, or export content.
Recent versions are created only before key actions that may overwrite the current working content.
Before Save
When you save new current content, DeMinds first keeps the previous working draft.
If the saved result is not as good as the previous state, you can find that earlier draft in Version History.
Before Restore
When you restore a historical version, DeMinds first keeps the current content.
This lets you return to the state before the restore if the restored version is not the right one.
Before Baseline Restore
Restoring the Baseline replaces the current working draft with the initial content.
Keeping the current content first prevents your edited work from being lost during that action.
Before Reparse
Reparsing, upgrading the parse result, or reimporting may rewrite the current Markdown.
Keeping a version before those actions lets you return to the existing working state if the new parse result is not suitable.
5. Compare, Restore, or Pin
Version History has three core actions: Compare, Restore, and Pin. They are used for different decisions.
Compare: check the change first
Use Compare when you are not sure whether the current content is better.
Compare is useful for:
- Checking whether heading hierarchy was disrupted
- Reviewing changes made by AI cleanup
- Confirming whether reparsing affected the body text
- Finding deleted or added sections
The comparison view is read-only. It is for reviewing differences, not for direct editing or partial merging.
Restore: return to a version
Use Restore when a historical version is better as a whole.
The selected version becomes the new current content. Before that happens, DeMinds keeps the current content as a Before Restore version, so one restore does not create another irreversible change.
Pin: keep a stable version
Use Pin when the current content or a historical version is worth keeping for longer.
Pinning is useful when you want to:
- Keep a stage after a round of cleanup
- Save a stable state before a large rewrite
- Leave a reliable reference for future changes
If the current content has unsaved changes, DeMinds asks you to save before pinning. This avoids pinning unconfirmed edits by accident.
6. Best-fit scenarios
Version History is designed for uncertainty around the most recent edits.
It is especially useful for:
- Long-document cleanup
- Markdown hierarchy adjustments
- AI-assisted rewriting or summarization
- Protecting current content before restoring the Baseline
- Protecting edited work before reparsing
- Comparing current content with an earlier state
If your goal is to edit freely while still being able to go back, Version History is the right tool.
7. What it is not for
Version History is not a full backup system, and it is not Git.
It is not intended for:
- Keeping unlimited history
- Managing branches
- Collaborative version control
- Recording every keystroke
- Replacing Workspace Backup
- Accepting or rejecting individual diff chunks
- Versioning images, attachments, or source files for every change
If you need to migrate a whole project, archive it long term, or preserve a workspace across devices, use DeMinds export, backup, or workspace features rather than relying only on Version History.
8. Safety principles
Version History is designed to prevent a single action from becoming irreversible.
- Before restore, DeMinds keeps the current content so you can go back again
- Historical versions are for preview, comparison, and restore; they are not edited directly
- The pinned version is not overwritten by recent versions and changes only when you pin again
9. What to know before using it
Version History mainly protects the current working Markdown.
Think of it as a recovery layer for the current working draft, not as a new entry point for content. Daily work still centers on the current content: edit it, preview it, export it.
A few details matter:
- Up to 3 recent versions are kept
- Up to 1 pinned version is kept
- The Baseline is the initial reference, not a recent version
- Restore keeps the current content first
- Compare is read-only and does not edit or merge
- Missing history does not prevent the current content from opening or being edited
10. Summary
DeMinds Version History is not about complex version control. It is about confidence while editing.
It keeps a few key states so that after saving, restoring, reparsing, or major cleanup, you can still understand what changed and return to a more suitable version when needed.