Explain the problem you see
In some cases, version tracking is a must. Now the only way is duplicating the node and moving it somewhere else – under the duplicated node or other "Older versions" node.
Why is this a problem?
It is causing structure to be more messy than necessary. In addition, every user could have a time where he changed a node and would like to change it back to it's previous state.
Suggest a solution
Hovering on the node or using command line prompt would allow to enter the history view of the node with dates of changes.
5 Comments
This is something that would be very valuable to me. I would also really like to be able to see versions and changes to nodes on the daily pages for the day they were added or changed, even if the nodes don't live on that day.
In other words, if I create a node on Monday and then edit it on Friday, I would like to be able to see on both of those daily pages that I interacted with that node (and how) on that day. I'm not exactly sure how to accomplish this, but it seems like something that could live under the references for the daily note.
Bump!
Having node-specific version history (in the fashion of something like google docs) would be amazing!
Would be a game changer too.
It would be easier for them to allow users to access their data locally so that they can use their own version control tool, as is possible with Logseq. For me, this is the most important missing feature. And it will solve offline issue at the same time. I don't know what their business plan is, but I have the bad feeling that we'll never have a visible copy of our data.
I'm also surprised that it only got 4 votes!
Being able to revert to a prior version of a node or supertag would be very helpful