History view

[okdistribute]

With the new SLEEP version, dat can download, save the changes, and revert to a previous point in history. It can also see a diff of which files changed. It could also see the content of the files that changed, but let's just have this iteration focus on looking at the history of changes and restoring to a previous point in time.

Here are some examples:

Restore to earlier version

While a file is open

Table view

GitHub history

GitHub Desktop App

[yoshuawuyts]

cool, thanks for sharing!

[Kriesse]

Example from Dropbox:

[martinheidegger]

DAT creates a lot of versions in a short time. It would be good to allow a DAT client to have some sort of "bundled versions" that act a little bit like Keyframes in Movies. Is there a system for this in place?

[martinheidegger]

Beaker-browser implements versions like this:

https://github.com/beakerbrowser/beaker/blob/37981f57d5c6f30aab0f94b72213d9505c272d78/app/builtin-pages/views/library-view.js#L685-L803

[dkastl]

For me the name version is a bit misleading, or it's not what I would expect as a user.

The current version history, that dat log returns is in my opinion limited useful: it can grow very long easily but does not provide much information beyond individual file changes. I would more expect something like git log.

[martinheidegger]

dat-ecosystem-archive/DEPs#5 (comment)

Version: Internally every dat data-structure is composed of append-only logs (hypercores). Any time an entry is appended to the log, a new version is created. The version is identified according to the semantics of the data-structure. In the case of single-writer hyperdrive, it's currently being identified by the metadata log's latest message number.

[AtuyL]

I'd probably say this feature's main purpose is historic lookup.
In conversation with Martin, it came out that the meaning of "version" is technically "history of file operations".

But is this really user-friendly?

Maybe: "Time based version" is better?

Every version entry also has metadata with a timestamp.
So, we can show squashed versions based on their timestamps. (i.e. chunks that happened within 5 minutes get squashed)

Users could also configure the time-span. (It would behave a little bit like a financial chart)

(This could probably done in the frontend alone, without changes on the DAT data)

[martinheidegger]

Regarding the time-stamps: In distributed systems "timestamps" are not trust worthy. They can be seen as rough estimates around which time the version probably happened.

In Git it usually works out in practice but its not reliable.

However: much more problematic about using time-stamps is that dat-log (that uses append-log) only stores the date of "put" operations in the "last-modified" metadata. Delete is not stored!

Related: mafintosh/append-tree#16

[AtuyL]

Thank you for clearing this up.

My suggestion required a timestamp of Delete and put. 😭 Need to rethink it...

[bnewbold]

Note: I've proposed self-reported timestamps (git style) to be included in hyperdb/hyperdrive:

• For Discussion: timestamps in hyperdb DEPs#11
• https://github.com/bnewbold/dat-deps/blob/dep-hyperdb-timestamps/proposals/0000-hyperdb-timestamps.md