You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an author I would like to have an mv-versioning attribute on the mv-app element, to specify that mavo should keep and provide access to multiple versions of my data. We get versioning for free on github, though there isn't a particularly elegant way to access the old version.
For access, it might be nice to trigger, via a url parameter or a config of the toolbar, access to a versions list; selecting from the versions list would load the data from that version. Having done so, there should be a way to reset the data to that currently-viewed version.
As for storage, since Mavo's target is small apps, I think it would be fine to just take periodic snapshot backups and store them under separate names in the specified storage. Periodicity, and the total number to keep, could be specified in the attribute, e.g. mv-versions="7 daily" to keep one a day for the past 7 days.
Related but separate, since Mavo is already keeping a history for undo purposes, it would seem theoretically possible to store the entire (again small) history for some period of time, which would allow undo to persist across multiple sessions.
The text was updated successfully, but these errors were encountered:
since Mavo is already keeping a history for undo purposes
It is not. The only thing you can undo is the last deleted item(s). We are tracking Undo functionality in #10 (wow, haven't seen a such a small issue number for a while!).
As an author I would like to have an mv-versioning attribute on the mv-app element, to specify that mavo should keep and provide access to multiple versions of my data. We get versioning for free on github, though there isn't a particularly elegant way to access the old version.
For access, it might be nice to trigger, via a url parameter or a config of the toolbar, access to a versions list; selecting from the versions list would load the data from that version. Having done so, there should be a way to reset the data to that currently-viewed version.
As for storage, since Mavo's target is small apps, I think it would be fine to just take periodic snapshot backups and store them under separate names in the specified storage. Periodicity, and the total number to keep, could be specified in the attribute, e.g. mv-versions="7 daily" to keep one a day for the past 7 days.
Related but separate, since Mavo is already keeping a history for undo purposes, it would seem theoretically possible to store the entire (again small) history for some period of time, which would allow undo to persist across multiple sessions.
The text was updated successfully, but these errors were encountered: