Hi all,
this is not the first time I am receiving a merge conflict resolution window while updating my image even though there is not a real merge conflict:
[cid:cdf93b35-01eb-4934-8ba1-bfc8bef8a86d]
Did anyone else of you experience similar issues in the past? Is there something wrong with the detection of merge conflicts?
Best,
Christoph
Nevermind, this one was a false alert, though it took me way too much to realize this. In my image, I already had recategorized this method, but in the Trunk, it is still uncategorized. Thus the merge conflict. :-)
Best, Christoph
----- Carpe Squeak! -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Christoph, yes we consider meta information like categories as editions and thus conflicts, and IMO it's a good thing because categories bring a bit of added value that we don't want to lose. A pity that I didn't see that those methods were miss-categorized, maybe it's not visually obvious when using message tracer...
Le sam. 1 mai 2021 à 14:00, Christoph Thiede christoph.thiede@student.hpi.uni-potsdam.de a écrit :
Nevermind, this one was a false alert, though it took me way too much to realize this. In my image, I already had recategorized this method, but in the Trunk, it is still uncategorized. Thus the merge conflict. :-)
Best, Christoph
Carpe Squeak!
Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Nicolas,
yes, it's only confusing because we don't have meta information for the author of a recategorization. Even though I see that this would likely be overengineering. :-)
A pity that I didn't see that those methods were miss-categorized, maybe it's not visually obvious when using message tracer...
Hmm, would it be a good idea to highlight the unclassified category in browsers using bold/italic font?
I've also been thinking for some time about displaying a small kind of dashboard in the SaveVersionDialog which could things such as: "slips" (halts/flags/Transcript) in code, uncategorized methods, and maybe even more things such as linter results (SwaLint) or test results. But this might be a performance problem and I guess that not everyone would like it ...
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Gesendet: Samstag, 1. Mai 2021 16:57:51 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] False merge conflicts
Hi Christoph, yes we consider meta information like categories as editions and thus conflicts, and IMO it's a good thing because categories bring a bit of added value that we don't want to lose. A pity that I didn't see that those methods were miss-categorized, maybe it's not visually obvious when using message tracer...
Le sam. 1 mai 2021 à 14:00, Christoph Thiede christoph.thiede@student.hpi.uni-potsdam.de a écrit :
Nevermind, this one was a false alert, though it took me way too much to realize this. In my image, I already had recategorized this method, but in the Trunk, it is still uncategorized. Thus the merge conflict. :-)
Best, Christoph
Carpe Squeak!
Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Am Sa., 1. Mai 2021 um 18:05 Uhr schrieb Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de:
Hmm, would it be a good idea to highlight the unclassified category in browsers using bold/italic font?
Put an exclamation sign on it, like the green and red bubbles for test methods. Or one of the flag icons (from flag:, halt, break) to signal unfinished work.
I've also been thinking for some time about displaying a small kind of dashboard in the SaveVersionDialog which could things such as: "slips" (halts/flags/Transcript) in code, uncategorized methods, and maybe even more things such as linter results (SwaLint) or test results. But this might be a performance problem and I guess that not everyone would like it ...
Would this be possible as an extension package that everyone can load if they want it?
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
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@student.hpi.uni-potsdam.de christoph.thiede@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]
Hi,
Am Mi., 29. Dez. 2021 um 22:01 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Well, can the merger actually merge append-only things?
Text merge cannot tell automatically which of two or more additions at the end must come first. And to conclude "it does not matter" it would need domain knowledge about these scripts. I see no such knowledge in MCThreeWayMerger>>#modifyDefinition:to:.
Kind regards, Jakob
Hi Marcel,
On Wed, 29 Dec 2021, Marcel Taeumel wrote:
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?
Appending stuff to the scripts is bad practice because the whole block will be evaluated every time. And most of the time those scripts are intended to be run only once.
However, there should always be a new update map when a script is changed.
Levente
Hi all --
Sure. Then, why is our CI able to update from 19432 (~April 2020) to 20916 (today) without merge conflicts in postscripts so far? I suspect that Christoph might have had an uncommited changed postscript in his local image?
Best, Marcel Am 30.12.2021 10:06:37 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Marcel,
On Wed, 29 Dec 2021, Marcel Taeumel wrote:
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?
Appending stuff to the scripts is bad practice because the whole block will be evaluated every time. And most of the time those scripts are intended to be run only once.
However, there should always be a new update map when a script is changed.
Levente
squeak-dev@lists.squeakfoundation.org