Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document "Single Installation Patching" To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47500#comment-10948 -------------------------------------------------- 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: Makes sense. 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". 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. --------------------------------------------------