Short answer: Keeping a mind map current is a small routine, not a rewrite. Date each branch, keep a change log in the root note, prune one branch per round, use undo and the 20-version history to step back, re-check the map against its source, and archive a copy when the topic closes.
Date the last change on each branch
A map goes stale quietly. Nothing looks broken; the branches are still there, they are just two months out of date, and nobody can tell which parts were checked. Putting a date on each branch is the cheapest fix, and it costs one short line in the branch note.
The date is not decoration. It tells the next reader which parts of the map are current and which are waiting for a check, and it tells you, the next time you open the map, where to spend the time. A branch last checked in March is a different thing from one checked last week, even when the labels are identical.
Keep the format simple and the same on every branch, such as "Checked 12 March, source: quarterly report". A date with a source behind it is more useful than a date alone, because it tells you where to look for the material the branch came from.
- One short line in the branch note, same format every time
- A date with a source beats a date alone
- A stale branch is one nobody has checked in months
- The date tells the next reader what is still current
Keep a change log in the root note
The root note is the right place for the map's own history, because it is the one node everybody sees first. A short list of what changed and when gives the whole map a version of its own, and it answers the question a reader always asks: is this the current version?
A change log is a bulleted list, and the root note supports exactly that, with bold, italic, underline, bulleted and numbered lists and an add-link control. Put the newest entry at the top, one line per round, with the date and the change in a single sentence.
Do not make it a diary. A log that records every keystroke stops being read. One line per round is enough, and the notes guide covers how to write and format the list so it stays readable.
- Newest entry first, one line per round
- Date plus what changed, in one sentence
- A link to the source goes in the same line
- A log past one screen means the map is changing too fast
Note: The root note is also where a reader finds the limits of the map, so the log and the scope of the map belong in the same place.
Prune one branch every round
Maps grow by addition and rarely shrink, so a map alive for a year has branches nobody would write today. Prune one branch per round, every time you do a pass, and a map keeps roughly the same size while its content stays accurate.
The branch to prune is usually obvious once you look. It is the one whose note says it was checked three months ago, or the one that duplicates another branch under a different name, or the one that belonged to an option you have since rejected. Move anything you are unsure about into a note rather than deleting it outright.
Pruning is where the review checklist earns its keep, because the review tells you which branch is stale and the prune makes the map smaller. A map that is the right size for its current content is a map people keep opening.
- Prune one branch per pass, every pass
- The oldest unchecked branch is usually the one
- Move a doubtful branch into a note rather than deleting it
- A map at the right size is one people keep opening
Step back with undo and version history
Every change to a map is reversible, which means you can be bolder than you would be in a text file. Undo and redo are shared across the canvas, the mind map and the App Builder, and the history keeps 20 versions, so the last twenty states of your document are one keystroke away.
The version-history panel goes further. It lists snapshots with timestamps, so you can compare a map as it was last Tuesday with the map as it is now, and roll back a bad round without undoing the good work that came after it. That is the difference between a history and a log of your own memory.
Use them for different jobs. Undo is for the last thing that went wrong. The version panel is for the round that went wrong last week, when you have since added two good branches. The undo guide covers the shared history in more detail.
- Undo for the last mistake, the panel for the last bad round
- The panel lists snapshots with timestamps
- History holds 20 versions, shared across canvas, map and builder
- Roll back a bad round without losing later work
Note: A snapshot covers the whole document, so a rollback takes the canvas and the App Builder back with the mind map.
Match the map to the current source
Now and then the map has to be checked against the material it came from, because sources move. Re-read the source, then re-read the map, and look for drift in both directions: something the source now says that the map does not, and something the map says that the source no longer supports.
Search makes the second direction quick. Press Ctrl/Cmd+F and the search looks in node labels and notes with ranked results, so you can test a handful of key terms one at a time and see immediately whether the map's version of them still matches. A term that no longer appears in the source is usually the branch that needs rewriting.
When a branch has genuinely changed, update the label and the note in the same sitting, then add a line to the root log. Half-updated branches are worse than stale ones, because a reader trusts them more.
- Check both directions: new in the source, unsupported in the map
- Use Ctrl/Cmd+F to test key terms one at a time
- Update the label and the note together
- Log every update in the root note
Archive the finished version
Some maps end. A project closes, a course finishes, a research question is answered, and the map stops being a working document. At that point the last useful thing you can do is freeze a copy, with a note saying the topic is closed and the date it was closed.
A copy is cheap in Canvasola. Export the map to Markdown, OPML, a plain-text outline, SVG or PNG, and you have a frozen copy that does not depend on the app being open. The Markdown export is the one worth keeping, because it stays readable in any text editor years later.
Keep the working file too, but mark it. Put "closed" and the date in the root note, so anyone who opens the map later knows it is a record and not a live plan. The complete Canvasola guide covers saving and opening project files, including the .canv format that stores the map, the canvas and the App Builder together.
- Freeze a copy: Markdown, OPML, plain text, SVG or PNG
- Put the closing date in the root note
- Keep the working file and mark it as closed
- A .canv project file keeps the map, canvas and builder together
A checklist you can reuse
- Every branch note carries a checked date and the source it came from
- The root note holds a change log with the newest entry first
- One branch was pruned in the last round
- A doubtful branch was moved to a note rather than deleted
- Undo and the version panel were used to check a round before moving on
- The map was re-checked against the current source
- A finished map was exported and marked as closed
Common mistakes to avoid
- Never deleting anything. A map that only grows ends up with branches that contradict each other. Prune one branch per round and the map keeps its size and its meaning.
- One date for the whole map. A single date in the root note tells you nothing about which part is stale. Date the branch, because the branch is what goes stale.
- A change log that reads like a diary. If every edit gets a line, nobody reads the list. One line per round, with the date and the change, is enough.
- Editing without logging. A map changed without a log looks untrustworthy, because a reader cannot tell what moved. Log in the same sitting as the edit.
- Treating history as a backup. The 20 versions in the history are a working safety net, not an archive. A finished map still needs an exported copy you can open without the app.
Frequently asked questions
How often should I update a mind map?
Every time the underlying material changes, and at minimum once a month for a live project. A map checked on a schedule stays accurate, while a map updated only when somebody notices a problem is a map that is wrong in small ways for months.
What if I have changed a branch a lot since the last version?
The version-history panel lists snapshots with timestamps, so you can roll back to the last agreed state and redo the change in a controlled way. The history keeps 20 versions, which is usually several rounds of work, and undo handles the most recent change in the current session.
Should I delete a branch that is no longer true?
Usually you should move it rather than delete it, especially when it records a decision that was made. Put the old branch and a one-line explanation into a note on the branch that replaced it, so the reasoning survives with the change.
Can two people maintain the same mind map?
Not by editing one document at the same time, because Canvasola does not support two people changing one map together. Cloud sync is opt-in and stores copies in the cloud, and an optional account holds 5 projects of 2 MB each, so the workable pattern is one person editing and a version handed over.
Give the map a maintenance routine.
Open a live map in Canvasola, add a checked date to one branch note, and start a change log in the root note so the next round has somewhere to start.
This guide is part of the mind map fundamentals collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.