Change the wording in snapshots

[Sasquatch]

Mark,
Please stop making this thread more and more confusing with the nonsense you're posting here. All I see is that you believe that when you have a file that contains the text '2', create a snapshot and add the text '3' to the file, you end up with '5' after the merge. That is total bull.

I'm sorry that my intent was not clear.

My "22","44" example was obviously nonsense and intended to show that merging snapshots is nonsense.

Think "snapshot" as according to a dictionary:
"In computer file systems, a snapshot is a copy of a set of files and directories as they were at a particular point in the past"
http://en.wikipedia.org/wiki/Snapshot_( ... r_storage)

At a particular point in the past, a file contained "22" and was copied into a snapshot.
At another particular point in the past, that file contained "44" and was copied into a snapshot.

Merging those two snapshots to get "42"?, or whatever is obviously nonsense, therefore merging is not a good UI term to use when dealing with snapshots.

People who know about the internals of VirtualBox (such as yourself) tend to see "Snapshot" and think "of course that also includes the difference hard-disks", even though they are not part of the UI.
YES Merge applies to the differencing hard disks as in your example, but 'Snapshot' != 'Differencing Hard Disk".

For your example that 22 + 44 = 42, not true, it will be 44, because 22 is replaced by 44. See it as file versions, you create a document, save it at work and mail a copy to your home. You continue the work at home and mail the new version to your work. At your work, you replace the document on the hard drive with the one you mailed from your home. That is what the merge option does. Old file versions are replace by the new versions. Same as when you update a program, install a Windows update or restore a backup. The existing file is replace by the file you modified last.

Now, what do you not understand from this?

[mpack]

People who know about the internals of VirtualBox (such as yourself) tend to see "Snapshot" and think "of course that also includes the difference hard-disks", even though they are not part of the UI.

You have said that several times, but I don't understand it. The VBox GUI shows a list of named "snapshots", one or more of these is what would be merged. In what sense is this not a part of the UI? Why does the existence of "differencing hard-disks" somewhere in the background invalidate the use of the word "merge" on those UI objects?

[MarkCranness]

For your example that 22 + 44 = 42, not true

I'm sorry I am not explaining this clearly enough.
I did not claim that 22+44=42. I claimed that 22 merged with 44 is nonsensical.

All of your explanations and examples I understand completely and I understand that they are referring to the state changes that occur.
Sets of changes can of course be merged just as you explain and are merged as you explain when snapshots as discarded.

Why does the existence of "differencing hard-disks" somewhere in the background invalidate the use of the word "merge" on those UI objects?

Because the changes / 'differencing hard-disks' ARE in the background, then 'Merge' which acts on those changes should not be in the foreground, because to do so is bad design.

If the changes were visible in the UI (they could be clicked-on and selected for example, like mpack suggested), then Merge would be an OK operation to perform on the changes.
But they are not in the UI, they are hidden and assumed, and therefore a visible operation that operates on invisible UI objects is not a good idea, that's all I'm saying.

Merging obviously happens on the differencing hard-disks, but unless the differences are part of the UI, an operation on them should also not be part of the UI.

Edit: Even though my circus / cat example was flippant, it DOES show clearly the problem I see with 'merging' snapshots.

[mpack]

Why does the existence of "differencing hard-disks" somewhere in the background invalidate the use of the word "merge" on those UI objects?

Because the changes / 'differencing hard-disks' ARE in the background, then 'Merge' which acts on those changes should not be in the foreground, because to do so is bad design.

Sorry, that argument makes no sense at all to me.

[MarkCranness]

Sorry, that argument makes no sense at all to me.

I'll try and make that argument more clearly: You wrote:

The wording used should make sense in the context of the UI model being offered to the user, it certainly does not need to be an accurate technical description of the underlying process. The user doesn't (or shouldn't) care that snapshots are stored in files, and that these files may vary in number as certain operations are carried out.

I would also add that the UI model offered to the user should not include objects that are only internal implementation details of the underlying process, or are specific to the particular implementation and might be different in a different implementation.

The differencing hard disks (and the changes they store) are specific to the particular implementation of snapshots that VirtualBox uses (this is what I meant when I said they were in the 'background', but that was not clear).
For the purposes of the snapshot UI, the user doesn't (and shouldn't) care that difference hard disks even exist, let alone how they are stored in files, and that they are updated as certain operations ar carried out (*).

Therefore the differencing hard disks (and they changes they store) should not be part of the UI model presented to the user.
Since any 'Merge' operation acts on the differencing hard disks (and they changes they store), then a 'Merge' operation should not be part of the UI model.


I imagine you don't agree with the "The differencing hard disks are specific to the particular implementation of snapshots" statement I make above.

My realisation of the problem with 'Merge' as an operation took some time to occur.

A few says ago I considered the difference hard disks to be an essential part of a snapshot, and had no problem accepting both 'Discard' and 'Merge' as descriptions of the Discard operation: The snapshot was discarded and the associated difference hard disks were merged into a neighbour snapshot (although at first I thought they were merged backwards into the differencing hard disk attached to the previous snapshot, rather than forwards into the the differencing hard disk attached to the following snapshot).

When one first sees the snapshot UI, you (one, anyone) immediately thinks: "I bet they don't actually copy the disks, I bet they only store changes between each snapshot."
After Googling, forum browsing and reading the source code, you know that the changes are stored in 'differencing hard disks' and have an idea of how they work.
You start thinking: 'Snapshot' = saved VM config + Differencing hard disk.
You start assuming that that is how it must work and there is no other solution.

To show that the differencing hard disks (=changes) are specific to the particular implementation of snapshots that VirtualBox uses, please consider this hypothetical alternative implementation of snapshots which does not include difference hard disks, nor the storing of any cumulative changes:

• To create a snapshot, make a literal complete backup copy of all disks (and other VM config).
• To revert to a snapshot, copy back the snapshot backup, overwriting all disks.
• To discard a snapshot, delete the backup files made.

VirtualBox could hypothetically implement this method of snapshots, and aside from grossly higher hard disk requirements and much slower speed, it would function exactly as the current implementation does.

The UI model is the same as the VB UI: Snapshots and the Current State. The operations are the same: Discard, Revert.
If you don't need to keep any of the snapshots (because you will never want to Revert to it) then Discard it.
If you want to return the VM to a state it was in the past, then Revert to the corresponding snapshot.

Do you agree that a 'Merge' operation makes no sense in this implementation?
How can you take a point-in-time copy of a disk and merge it with another point-in-time copy of that disk and get anything meaningful?

Now suppose we change the implementation, and we decide to store the snapshots in a more space efficient way: We decide to only store differences since the previous snapshot.

Does this change in the internal implementation detail also change the UI model presented to the user?
I think it largely does not: the same UI model still works, and 'Merge' still makes no sense when applied to a snapshot (*).

Of course, a Merge operation does make sense if applied to the differencing hard disks, but they are not part of the minimal UI model.

Note: (*) In cases where the user does care about where the snapshot files and difference hard disks are stored, such as file backup of those files, then the internal implementation details of the process become important. Why is there always an exception to every rule!

[mpack]

This discussion seems to be becoming extremely esoteric and detached from the original OPs point...

The UI model offered to the user must bear some relationship to the purpose of the operation, if users are to have a hope in hell of understanding it. The entire purpose of the snapshots feature is to separate one group of changes from another group of changes, for the purposes of implementing a kind of "undo". Now Changes==Differences, and I don't see how the UI model can possibly ignore that. My only contention was that the UI model doesn't need to rely on the fact that (group of changes)==(VDI file), and it doesn't.

Furthermore, the "merge" operation itself, regardless of what we call it, must be present because it's a prerequisite for many things that users want to do: for example safe backups, cloning, and easily moving VMs between hosts. Arguing that "merge" shouldn't exist because of the dictionary definition of the word "snapshot"... well, I don't regard that as useful advice. "Snapshot" may indeed be another ill-chosen word, but it is probably here to stay despite that.

[Sasquatch]

MarkCranness, you obviously don't understand what it's all about with the snapshot feature. I'm not even going to waste my time and energy explaining it to you.

[MarkCranness]

@Sasquatch: Was there a constructive reason for that insult?

Given that much of your recent advice to posters about snapshots has been wrong, I am thankful that you will no longer waste your time and energy explaining them to me.

MarkCranness Edit: Deleted links.

[Sasquatch]

Mark, that was when I too had no idea how it really worked. The users who started with this thread had a very good explanation and I only recently learned the exact meanings of them. Now, don't go lecture me, you're just a rookie here on the forums with way to much free time and focused on only one subject. My knowledge far exceeds yours here.

[MarkCranness]

Sasquatch, thank you for your diplomatic response. I'm sure your knowledge here does far exceed mine here. I am sure that I understand more about snapshots than you think I do.

[MarkCranness]

Edit: It's more complicated than I thought, my suggestions below do not always work / are not always appropriate. See post below

Furthermore, the "merge" operation itself, regardless of what we call it, must be present because it's a prerequisite for many things that users want to do: for example safe backups, cloning, and easily moving VMs between hosts.

This is an important point, and one I have missed/ignored so far.

(Do I understand the prerequisite correctly, when I say:)
Although not obviously exposed by the snapshot UI, once a snapshot is taken, the base VDI file is static/read only (does not contain any further changes).
This feature is an important part of how snapshots work and also an important part of the user's conceptual model.
For (the reasons you gave above) the user must be aware of how this works, and that they will need to remove all snapshots so that the base hard disks include all changes so far.
(Is the "static/read only base VDI" point the only/main point here, or is there some other aspect of the differencing hard disks that is also important?)

Consider this wording for the Discard button, used when there is one only last remaining snapshot:

Discard Snapshot and Copy Current State to Hard Disks
(I imagine you would prefer a much shorter version of: "Merge Current State into the Hard Disks, then Discard Snapshot")

When there is more than one snapshot, use this wording for the Discard button, used ONLY for the first snapshot:

Discard Snapshot and Copy Following Snapshot to Hard Disks
(I imagine you would prefer a much shorter version of: "Merge the Following Snapshot into the Hard Disks, then Discard This Snapshot")

When there are more than 2 ('n') snapshots, use this for snapshots 2 thru n-1 (ie not the first snapshot, and not the last snapshot):

Discard Snapshot
(I imagine you might, maybe, prefer a much short version of: "Merge This Snapshot into the Following Snapshot, then Discard This Snapshot")

(I've only recently learnt that discarding the first snapshot does a backwards merge of the following snapshot's differencing hard disk into the base VDI, and that discarding the second, third and so on snapshots does a forward merge of that snapshot's differencing hard disk into the following snapshot's differencing hard disk.
If we are on the same page re. backwards/forwards as above, then no more need be said, but otherwise let's please discuss that.)

Edit: Edited for length.

[Perryg]

Mark,
Can you for the sake of GOD make these shorter? I am really having a hard time trying to wrap this into anything worth while. I think that we have gotten the idea that you are not happy with the snapshots the way they are. I gave up on them a long time ago myself but come on really any more discussion and it will look like you are just wanting to hear yourself talk. So for your sanity and mine just accept that they are broken in your world and move on.

[Sasquatch]

Sasquatch, thank you for your diplomatic response. I'm sure your knowledge here does far exceed mine here. I am sure that I understand more about snapshots than you think I do.

That might certainly be true, given the extensive posts you've written so far. I've even learned a thing or two from it. This might be the only subject where you know more than me.

[MarkCranness]

@mpack: Thank you for your discussion and engagement to date; I have found it helpful.

(I removed these points from my last post in an attempt to shorten it, but I'm putting them back again.)

This discussion seems to be becoming extremely esoteric and detached from the original OPs point...

Esoteric yes, but maybe some clarity might result, which might help all.
I attempted to create a new thread for my label suggestions, but that was closed and I was pointed to this thread instead.

The UI model offered to the user must bear some relationship to the purpose of the operation, if users are to have a hope in hell of understanding it. The entire purpose of the snapshots feature is to separate one group of changes from another group of changes, for the purposes of implementing a kind of "undo". Now Changes==Differences, and I don't see how the UI model can possibly ignore that.

Separating groups of changes is one way of thinking about it, and point-in-time capturing a snapshot of the system state is another. They are complimentary, and either will work.
I can see how the UI model can ignore the changes and concentrate on the point-in-time snapshots, or at least I'd like to explore the idea that it could.

My only contention was that the UI model doesn't need to rely on the fact that (group of changes)==(VDI file), and it doesn't.

Agreed.

Short but clear is obviously good, but short and ambiguous is not necessarily bad. What is important is that each feature must have a clearly distict name that fits on a button, and which doesn't misuse words which people normally interpret as meaning something else (i.e. "discard"). Ambiguity gets resolved by familiarity: I say this because I doubt that any wording would be completely satisfying and unambiguous to everyone right away.

I am seeing the truth of this more and more!
My recent suggestions are probably too long for popup context menu labels, but perhaps OK for tooltips or status bar text.

Can you for the sake of GOD make these shorter? I am really having a hard time trying to wrap this into anything worth while. I think that we have gotten the idea that you are not happy with the snapshots the way they are. I gave up on them a long time ago myself but come on really any more discussion and it will look like you are just wanting to hear yourself talk. So for your sanity and mine just accept that they are broken in your world and move on.

I tend to waffle and I'm sorry about that; I will try not to.

I saw problems with the snapshot labels. I googled and found many people saw problems, but there was no substantive discussion on how to fix them.
I hoped (and still hope) that by starting a discussion the problem could be fixed.

[MarkCranness]

It's more complicated than I thought and my suggestions above are not always applicable.

It is NOT if it is the first snapshot that determines whether a merge backwards into a base Hard Disk occurs or not.

It depends upon if the snapshot hard disk attachments are base hard disks or differencing hard disks.

• The first snapshot in a VM may have a differencing hard disk if that hard disk was also attached to other VMs and was snapshotted on that VM when it was added to the first VM.
• The second or subsequent snapshot can have base hard disks attached if they were attached after the snapshot was created and no other VM had snapshots on that hard disk.
• A snapshot with multiple hard disks may have some base hard disks attached and some difference hard disks attached.