Apply a revert that does not contain updates generates a history rollback entry

[yersan]

It is a bit weird to see a history entry since there were no changes at all on the current installation.

It is easily reproducible by installing a new server and reverting to the initial hash revision. The history ends with a new rollback entry that does not contain changes at all.

[spyrkob]

Thanks @yersan. I guess we should check if the requested hash != current hash in revert operations. That should avoid this scenario?

[yersan]

Well, not sure if that fully addresses this. I think we could get situations where you are reverting to a version that doesn't contain changes when compared with the current one. For example:

hash-6 -> revert to hash-3
hash-5 -> revert to artifact.1.0.0
hash-4 -> upgrade to artifact.1.0.2
hash-3 -> revert to artifact.1.0.0
hash-2 -> upgrade to artifact.1.0.1
hash-1 -> base artifact.1.0.0

hash-6 reverts to hash-3 which are effectively different hashes but since it tried to revert to the same version currently installed, there are no changes applied, however, you get a rollback hash. If you check the list of changes in hash-6, you will get nothing.

Take it as a kind of enhancement, I don't think it is a big concern and, after all, the tool is doing what is expected to do. I've just opened this for your consideration and just in case there could be other unwanted side effects.

[spyrkob]

Ah yes, good point. OK then we'll need to compare the state before revert ops. Thanks!

[spyrkob]

We should add two checks:

1. Before generating candidate, check that the hash is not the same as current one
2. After generating candidate but before applying it verify there are any changes

If any of those fail, the operation should be rejected and a warning should be printed for the user