I hope there wouldn't be a conflict if the update map would have been updated for the changed postscript? In that case: Thanks for this tip! I will try to either only append stuff to the postscript or update the update map if I also remove stuff. Well, can the merger actually merge append-only things?

Best,
Marcel
Am 29.12.2021 21:18:25 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi all,

I now saw this at least for the second time: While updating an older Trunk image to the latest Trunk version, a merge conflict for the postscript of a package needs to be resolved. In my example, Morphic-mt.1801 is being merged into an image with Morphic-ct.1789 with an empty working copy. In [] in MCThreeWayMerger>>modifyDefinition:to:, the three (!) different versions of the script look like this:

baseDefinition
    SystemProgressMorph reset. "New layer number"

targetDefinition
    SystemProgressMorph reset. "New layer number"
    
    "Morphic-ct.1796 - Inverts the preference 'halo encloses full bounds' by pressing the control key while invocating a halo."
    (Preferences preferenceAt: #haloEnclosesFullBounds) instVarNamed: 'helpString' put: 'If enabled, halos will enclose the full bounds of the target morph, rather than just the bounds.     You can also invert this behavior temporarily by holding down Ctrl while invoking a halo on a morph.'.

other
    TextEditor withAllSubclassesDo: [:editor | editor initialize]. "recreate menu morphs to update their morphic layer number"

I am unsure what would be the right way to fix this issue. Can we assume that the former script has already been run and always choose other? Or do we need to run both target and other? As (update stream) postscripts *should* be idempotent, could we just append some of the postscripts - e.g., by adding some extra logic to the exception handler in MCConfiguration >> #upgrade? Or where else are we missing a piece of logic?

Best,
Christoph

---
Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211229/ba6cf396/attachment.html>