mpack wrote:Sorry, that argument makes no sense at all to me.
I'll try and make that argument more clearly: You wrote:
mpack 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!