Merging Algorithm Question

> Hi
>
> I have a question.
> Imagine the following scenario.
>        - jannik used 11005 to remove heading. In his version morphic has the
> class Presenter as well as methods in other classes related to etoys.
>        - in 11010 we remove Presenter and other methods.
>
>        - now in 11030 I'm merging Jannik changes and
>        I do not understand why Presenter and the methods that were remove in
> 11010 are not in conflicts.
>        I see just that Presenter and the methods removed are added again.
>        Did I miss something obvious?
>
> Stef
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>> I have a question.
>> Imagine the following scenario.
>>        - jannik used 11005 to remove heading. In his version  
>> morphic has the
>> class Presenter as well as methods in other classes related to etoys.
>>        - in 11010 we remove Presenter and other methods.
>>
>>        - now in 11030 I'm merging Jannik changes and
>>        I do not understand why Presenter and the methods that were  
>> remove in
>> 11010 are not in conflicts.
>>        I see just that Presenter and the methods removed are added  
>> again.
>>        Did I miss something obvious?
>>
>> Stef
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On Nov 4, 2009, at 9:38 PM, Lukas Renggli wrote:
>
>>> Lukas in my example in fact Presenter was removed as well as other
>>> methods.
>>> Then since they were present at the time jannik commited they
>>> reappear
>>> when I merge
>>> and I do not see why they are not at least tagged with conflicts.
>>
>> If you remove Presenter and Jannik does not touch it, then it should
>> remain removed after the merge.
>
>
> yes this is what I thought (or at least a conflict)
>
>> If you remove Presenter and Jannik does touch it, then you should get
>> a conflict.
>
> Yes this is what I thought too :)
>
>> Presenter can only reappear, if in your delta or in the delta of
>> Jannik the Presenter is added (which doesn't seem to make sense, so I
>> don't understand).
>
> me neither :)
> because Jannik did not touch it.
> Can you give a try to do a merge of heading removal in the latest 1,1
> image to see
> if you get the same behavior.
>
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> 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
>

>
> Lukas
>
>
>
> 2009/11/5 Stéphane Ducasse <[hidden email]>:
>>
>> On Nov 4, 2009, at 9:38 PM, Lukas Renggli wrote:
>>
>>>> Lukas in my example in fact Presenter was removed as well as other
>>>> methods.
>>>> Then since they were present at the time jannik commited they
>>>> reappear
>>>> when I merge
>>>> and I do not see why they are not at least tagged with conflicts.
>>>
>>> If you remove Presenter and Jannik does not touch it, then it should
>>> remain removed after the merge.
>>
>>
>> yes this is what I thought (or at least a conflict)
>>
>>> If you remove Presenter and Jannik does touch it, then you should  
>>> get
>>> a conflict.
>>
>> Yes this is what I thought too :)
>>
>>> Presenter can only reappear, if in your delta or in the delta of
>>> Jannik the Presenter is added (which doesn't seem to make sense,  
>>> so I
>>> don't understand).
>>
>> me neither :)
>> because Jannik did not touch it.
>> Can you give a try to do a merge of heading removal in the latest 1,1
>> image to see
>> if you get the same behavior.
>>
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> http://www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Wait, I merged the wrong thing. I should have loaded
> SLICE-issue496-headingRemoval-jannik_laval.2.
>
> Now I can explain the situation:
>
> - SLICE-issue496-headingRemoval-jannik_laval.2 depends on
> EToys-jannik_laval.118.
>
> - In my Pharo 1.1. image there is EToys-StephaneDucasse.1, which is an
> empty package.
>
> When you merge changes, Monticello calculates the delta between the
> common ancestor (EToys-StephaneDucasse.1) and the two versions you
> merge.
>
> - EToys-StephaneDucasse.1 to EToys-StephaneDucasse.1 is an empty  
> delta.
>
> - EToys-StephaneDucasse.1 to EToys-jannik_laval.118 is EToys-
> jannik_laval.118.
>
> Obviously there are no conflicts and Monticello just loads
> EToys-jannik_laval.118. It looks to me like the wrong base package is
> loaded in Pharo 1.1.
>
> Cheers,
> Lukas