[aawsome]

Adds the possibility to compare two snapshots interactively.
From the interactive snapshots view, press D to get to the diff view.
If two snapshots are marked, this diffs the two marked snapshots. If one snapshot is marked or selected, this diffs with its parent (if there is one).
Alternatively, you can use rustic diff -i to select snapshots/paths directly.

The PR also allows to recursively compute added/removed space for dirs and subdirs using s (like in #1479)

This PR is breaking as it also changes the output format of the normal diff command.

[DianaNites]

First of all, thank you very much for working on this, I use and enjoy rustic a lot.

Initial thoughts: the --version should probably include the commit SHA, preferably the full size one, if available. Right now theres no way to determine that my rustic 0.9.5 is actually rustic commit aae3426cb8f8619d4afc5ca09759396cc5b0f82d

Actually I see theres already a PROJECT_VERSION for this purpose, and build.sh uses it

Some sort of progress while computing the sizes would be nice, as right now it just freezes until its done. It took about a minute or so before it was responsive again for me.

Now that its done: The sizes seem to be just bytes, which is difficult to parse at a glance. It would be nice if there was a toggle between "human units" and "raw bytes", because most of the time its a large magnitude difference i want to see at a glance(ie, GB vs MB, the exact size is usually noise, but the option is nice to have), and also duplicated in the headers? or different?

Oh wait, as i was writing this i realized the sizes are probably? for the two selected snapshots? but which is which? is it the order i marked them? Their values are also maybe are partially off-screen? Perhaps there should be a shortcut to show details in a popup, like the i one on the snapshot list for viewing snapshot details?

That would mean it can be far more verbose, with information like "In Snapshot () from , this folder was " for the two selected snapshots. That would be really useful, because i dont know which ID, or which the - and + in the headers, is which snapshot but i will know which i want to be comparing, and in which direction, if i know when they were made.

I assume RepoSize is the size in the actual repo, with compression and etc, and Size is the theoretical on-disk size?

m to toggle metadata doesn't seem to do anything, as far as I can tell, for either files or folders?

Also something that would be nice, the ability to see the snapshot information for the two snapshots i am comparing, my working memory is short so i forgor. Maybe I(shift+i`) and a tabbed view between the two snapshots? This, and the popup to view detailed size differences between the selected snapshots instead of column headers I suggest above, would also generalize nicely to comparing more than just two snapshots.

Also I accidentally backed out back(using the left arrow key) to the snapshot selection screen, and comparing them again noticed: My choice for whether to show only modified files remained, but the size computation had to be done again. Perhaps a prompt to confirm backing out?

Thank you very much for your time

[aawsome]

Thanks for testing this PR @DianaNites and for your improvement suggestions!

You already found build.sh. I don't know if there is a better option to set the version...

Some sort of progress while computing the sizes would be nice, as right now it just freezes until its done. It took about a minute or so before it was responsive again for me.

I agree. A progress bar is however hard as we need to recurse into subtrees and cannot say how many trees to load. I'll add an "in progress" information. But I don't know if I may postpone this to a later version..

It would be nice if there was a toggle between "human units" and "raw bytes",

I changed it to use human units. If you need to toggle, please open a feature request ;-)

Oh wait, as i was writing this i realized the sizes are probably? for the two selected snapshots?

Yes, sizes and modification times are for old and new snapshot.
I'll add the table description to show which is which.

I assume RepoSize is the size in the actual repo, with compression and etc, and Size is the theoretical on-disk size?

Yes, exactly. But currently only file sizes are taken into account while tree metadata size is neglected.

m to toggle metadata doesn't seem to do anything, as far as I can tell, for either files or folders?

For files, it works but if you only have changed content in combination with changed metadata, there won't be any difference in those views...
For dirs, this information can only be recursively determined. I planned to add this to 's', but it is a bit complicated. I might also postpone this for later...

Also something that would be nice, the ability to see the snapshot information for the two snapshots i am comparing, my working memory is short so i forgor. Maybe I(shift+i`) and a tabbed view between the two snapshots? This, and the popup to view detailed size differences between the selected snapshots instead of column headers I suggest above, would also generalize nicely to comparing more than just two snapshots.

Good idea, I'll see if I can add it soon!

Perhaps a prompt to confirm backing out?

Is added.

[aawsome]

Ah, and one comment about the +/-Reposize:
Note, that this depends on the current level of subdirs we are actually comparing and does not need to be the sum of +/- Reposize of the contained items, due to the deduplication which is taken into account in the calculation! In fact the +/- Reposize is smaller or equal than the sum of the contained items.

For example, you can have big changes on RepoSize when comparing 'dir/a' (old/new) and 'dir/b', respectively, but only have a small change when comparing 'dir'. An extreme example is when you renamed some dir. This obviously does not contribute to the RepoSize, but once you dive into the old or new dir, you will only see added or removed space;-)

[DianaNites]

I agree. A progress bar is however hard as we need to recurse into subtrees and cannot say how many trees to load. I'll add an "in progress" information. But I don't know if I may postpone this to a later version..

It does know the current one and how many its done so far, right? Something like "Computing (/??), a sign that forward progress is being made

[aawsome]

@DianaNites progress information and the title showing snapshots/current path has now been added.

[DianaNites]

Thank you, the progress seems to be working fine and is very useful.

[aawsome]

Most features are now implemented @DianaNites, can you have a look if things are like you expected?

The i info is missing. Can you briefly depict which information you want to see when pressing this? Thanks!

[DianaNites]

Thank you so much once again for your work on this. I have already been able to find and exclude from backup a few unnecessary and fairly large cache directories i'd missed excluding.

Testing the latest commit, be3fe53, the I command doesnt seem to be in the help, but otherwise works fine.

The information currently displayed is perfectly usable right now, and has the information I need so I know and don't have to keep in my head what i'm comparing, their relative sizes, description, dates.

Unrelated to the I command, something to show the current filters(d and m) would be nice, it is often hard for me to tell which view is currently enabled especially for m.

Also the paths in the header are nice to see and especially copy paste, but become difficult to see/use for deeply nested paths because the same path is shown twice, once for each snapshot. Its not actually possible for them to differ in this view, right?

[aawsome]

Thanks @DianaNites for testing!

The I is now added in the help and a status line has also been added.

Also the paths in the header are nice to see and especially copy paste, but become difficult to see/use for deeply nested paths because the same path is shown twice, once for each snapshot. Its not actually possible for them to differ in this view, right?

In fact it is possible to differ, as rustic diff -i is now also implemented and this allows to specify two different paths to diff... I think I'll leave it as it is for now. We can improve things later if this is a real problem for many people...