I previously sent this via email, but now that yesterday's jboss.org issues are cleared up, I'll repeat it for others to see:
Jeff Mesnil wrote:
Brian Stansberry wrote:
What's in thie previous-cumulative file? Just the name of the applied to version?
Yes, for history purpose, I think it's important to tell the user which version the patch has been applied to (among all the acceptable <applies-to-version> of the patch). He would want to know what will be the resulting version of a rollback prior to perform it.
Makes sense.
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.
This contradicts the previous sentence about cumulative patches invalidating all one-off patches.
Once the patch is applied, any change made by an earlier one-off patch needs to be removed. That's what I mean by "invalidating."
What I'm talking about in the paragraph above is related to the "Patch Conflict Detection" algorithm discussed on the main article, in particular the "Misc files" part. The goal is to detect *end user modifications* to the misc files and require the user to declare that overriding that modification with the patch is OK.
Say we have a 6.1.1 CP patch with an applies-to version of 6.1.0. The patch.xml includes a mod to standalone.sh with an existing-hash of "123", the hash of the file present in 6.1.0.
But the user has already applied a one-off that changed the file to one with hash "234". Quite possibly the same hash as the new file in 6.1.1, but not necessarily.
The patch application tool should understand that given the status of the installation "234" is now the expected "existing-hash" for the file and should recognize there is no conflict requiring user input. To do that it will need to know that one-off patch XYZ changed the file to one with hash "234".
what do you think of this "stack" representation of the patches? Is it correct?
Yes, that's correct. I have doubts about relying on dates for ordering. They are useful for providing information to users about when they did things, but I think we'd be better off specifically maintaining an order.