Jeff Mesnil wrote:
Thinking about this raises some questions about patches metadata.
Can we apply multiple CP one after the othe (e.g. CP for 6.0.1->6.0.2 then CP for 6.0.2->6.0.5) or can we apply only 1 CP per installation?
It's my understanding that applying a CP invalidates all the applied one-offs but I can not find this stated anywhere, am I mistaken?
Multiple CPs can be applied one after another. This would be a typical progression for a long lasting installation, e.g. start with EAP 6.1.0 then apply 6.1.1 then later 6.2.0, then later 6.2.1 etc. Technically, a patch could be generated that takes the installation all the way from 6.1.0 to 6.2.1, but whether that would be done for any particular release combination is up to the folks creating and distributing patches.
Yes, applying a CP invalidates all the applied one-offs.
If one-offs can only have been applied to the current CP (or the base version)., that means that in the history, only CPs have a cumulative file containing the *previous cumulative* (renaming the file to previous-cumulative makes it simpler to understand)
What's in thie previous-cumulative file? Just the name of the applied to version?
I think we are going to need to store the patch.xml, which contains that information plus much more. That or something similar. For sure we are going to need to store the hashes of any files changed in a one-off patch, plus data about any misc file changes that the user elected not to have applied. We'll need this information for when we apply a CP on top of a one-off patch. The CP will include existing-hash data for the base version against which it was built, but when we check for modifications (i.e. conflicts) we will need to compare against what was in the one-off patch. In that case the existing-hash data in the patch.xml file will not be the relevant hash; the tool will need figure out from the patch history what the expected existing-hash is for what's actually installed.
I also have a question about rollback. From the spec, I understand we want to rollback to a previous point in history. But we will not provide a way to rollback a given patch. Is that correct?
From the concrete example above, the user will not been able to rollback the patch-XX-oneoff (while keeping the patch-YY-oneoff). In order to do that, he must: 1) rollback to the point in history before the patch-XX-oneoff has been applied, 2) applies again all the patches after it.
I regard being able to roll back XX but not YY as being a nice to have, but not a requirement, particularly for this first version. However, I'd like us to consider how to do it and try to design for it, even if we don't in the end formally support it. My instinct is that an algorithm that can take the patch content, the history, the current installation, and arguments from the user declaring how to handle conflicts and use that data to figure out what to do with each file in the installation -- that would be the most robust algorithm, the one less likely to have big "oops" holes in it that we'd discover later.