On 2013-10-27, at 20:23, Stéphane Ducasse <[email protected]> wrote: > On Oct 27, 2013, at 6:18 PM, Camillo Bruni <[email protected]> wrote: > >> Things got updated: >> >> The tracker job >> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ has >> now a version number check + the recent pharo version allows the #update >> command line handler >> to detect if wrong update files were specified. Together with Stef's fix to >> always >> merge updates the update process should now be more stable. > Tx camillo. > > Pay attention that my change is to ignore conflict warning
I am not fully sure about that, since there are two steps required:
1. MCMergeOrLoadWarning
2. MergeResolutionRequest
From what I got, you only deal with the first one, which asks the user if he
wants
to merge or not (which for instance in git never happens). The second one
actually
does the merging. I am pretty much convinced that we don't need the two of
them, since
I see that we basically spread the following code all over the place:
[aLoadBlock
on: MCMergeOrLoadWarning do: [ :request | request merge ]]
on: MCMergeResolutionRequest do: [ :request | request autoMerge ].
The real merge conflict is only available in the MCMergeResolutionRequest,
before it
is a warning that is solely based on whether a package is dirty or not, a very
crude
approximation of a conflict...
signature.asc
Description: Message signed with OpenPGP using GPGMail
