It means that we both changed the same method, so there is a merge conflict.
Right now, the method for resolving is binary:
If you say keep, then you accept the incoming version to replace your
version.
If you say reject, then refuse the incoming version and prefer to keep your
own version.
I guess that you'll want to manually merge our both changes once the load
is complete.


2013/9/21 Bob Arning <arning315 at comcast.net>

>  Ran mostly without problem. Got one of those monticello merge-whatever
> windows complaining about TheWorldMenu>>soundEnablingString. I clicked keep
> and merge and it went away. Whatever that means.
>
> Cheers,
> Bob
>
>
>  On 9/21/13 5:38 PM, Nicolas Cellier wrote:
>
>   So Monticello-nice.571 is using a message added in Compiler-nice.270
> So does Kernel-nice.808
> That means that I should have placed Compiler-nice.270 in an intermediate
> update or higher in the package order...
>  I just republished update-nice.246.mcm with Compiler raised two places
> abaove (above Monticello and Kernel).
>  Could you retry?
>
>
> 2013/9/21 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>
>>  Ah, probably a problem with load order.
>>  I will check that.
>>
>>
>> 2013/9/21 Bob Arning <arning315 at comcast.net>
>>
>>>
>>> ========== Graphics-tpr.225 ==========
>>>
>>> An attempt to improve the comment for BitBlt; it was very out of date
>>> (no Patterns or MAskedForms in image now) and more than a bit confusing in
>>> places. Hopefully this is less so.
>>>
>>> ========== Monticello-nice.571 ==========
>>>
>>> Don't pass a category to a Compiler, classifying is not its job.
>>>
>>> >>> Monticello-nice.570 <<<
>>> Now that the SyntaxError restarts the existing Compiler process rather
>>> than substitute to it, it is possible to edit method with incorrect syntax
>>> in the SyntaxError and continue MC Loading/Merging.
>>>
>>> Though, we should log the corrected code, not the syntaxically incorrect
>>> one, and for that we let MethodAddition intercept the
>>> SyntaxErrorNotification so as to retrieve its corrected newSource.
>>>
>>> ========== Kernel-nice.808 ==========
>>>
>>> Don't pass a category to a Compiler, classifying is not its job.
>>>
>>> >>> Kernel-nice.807 <<<
>>> If you just need the parameter names, then just ask for the parameter
>>> names.
>>> Asking for parameter and temp names, then throwing the temps away sounds
>>> like not using the right API in the right place...
>>>
>>> ========== Graphics-tpr.225 ==========
>>>
>>> An attempt to improve the comment for BitBlt; it was very out of date
>>> (no Patterns or MAskedForms in image now) and more than a bit confusing in
>>> places. Hopefully this is less so.
>>>
>>> ========== Monticello-nice.571 ==========
>>>
>>> Don't pass a category to a Compiler, classifying is not its job.
>>>
>>> >>> Monticello-nice.570 <<<
>>> Now that the SyntaxError restarts the existing Compiler process rather
>>> than substitute to it, it is possible to edit method with incorrect syntax
>>> in the SyntaxError and continue MC Loading/Merging.
>>>
>>> Though, we should log the corrected code, not the syntaxically incorrect
>>> one, and for that we let MethodAddition intercept the
>>> SyntaxErrorNotification so as to retrieve its corrected newSource.
>>>
>>> ========== Kernel-nice.808 ==========
>>>
>>> Don't pass a category to a Compiler, classifying is not its job.
>>>
>>> >>> Kernel-nice.807 <<<
>>> If you just need the parameter names, then just ask for the parameter
>>> names.
>>> Asking for parameter and temp names, then throwing the temps away sounds
>>> like not using the right API in the right place...
>>>
>>> ......then a walkback (attached)..........
>>>
>>> Cheers,
>>> Bob
>>>
>>>
>>>
>>>
>>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130922/31522427/attachment.htm