Problems with MC (was Re: May be some problems with MC history)

> Thanks dave.
> So far I found my way (but I will have a look) and I'm reading
> carefully the code to see
> the implication for the loading of the closure fixes.
>
> Stef
>
> On Sep 12, 2009, at 3:45 PM, David T. Lewis wrote:
>
>> On Fri, Sep 11, 2009 at 01:48:45PM +0200, Lukas Renggli wrote:
>>>> a couple of bugs when understanding the history based merge (ugly)
>>>
>>> It is not a merge operation, as I said in my mail. You are merely
>>> applying the changes representing a delta between two versions
>>> manually. That's all, no magic involved.
>>>
>>>> ? ? ? ?- adding the new method to a cs does not work if you did
>>>> not install
>>>> the code before (ok)
>>>> ? ? ? ?- class definition are not added (yeah) in the changeset.
>>>> Really cool!
>>>
>>> I don't understand what this has to do with change-sets?
>>>
>>> Class definitions are part of the patch that is calculated by
>>> Monticello. My guess is that the class didn't change for the delta
>>> you
>>> calculated. To illustrate, in the example above the changes between
>>> b.1 and b.2 don't show a class change that happened between a.1 and
>>> b.1, even if the delta depends on it.
>>>
>>> I use what I described all the time, it is maybe a bit tricky, but
>>> works really well.
>>
>> Stef,
>>
>> I don't know if this is helpful or not, but FYI Edgar De Cleene has
>> produced the list of change sets corresponding to the MC update stream
>> for Squeak trunk. See this thread on squeak-dev:
>>
>>  http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-September/139360.html
>>
>> Dave
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> I just publish a couple of MC packages in the inbox
>
>        one just to fix a bad reference to ChangeSorter instead of
> ChangesOrganizer (not needed so far)
>        one for 309 (which was a kind of changes to support atomic loading)
> but did not really helped
>        one for 321 where andreas patched that so that they could load
> closure fixes
>        one with installAll menu in MCPatchBrowser :)
>
> So let me know if this is working.
> I could load eliot fixes for kernel (package two = step two of the
> eight) without problem.
>
> Stef (now I'm sick so going to bed).
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>