Merging Algorithm Question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Merging Algorithm Question

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Merging Algorithm Question

Lukas Renggli
Can you elaborate the ancestry of the code?

- What is the ancestry of your image?
  (e.g. 11005, 11010, 11030)

- What is the ancestry of the code you merge?
  (e.g. 11005, 11010, XXXX)

In the example above the common ancestory is 11010. So what Monticello
does is to load the delta between 11010 and Janiks branch XXXX. If
this does not touch any changes that have been made between 11010 and
11030 there is no conflict and that can be merged automatically.

Lukas

2009/11/4 Stéphane Ducasse <[hidden email]>:

> 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
>



--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Merging Algorithm Question

Stéphane Ducasse

On Nov 4, 2009, at 3:53 PM, Lukas Renggli wrote:

> Can you elaborate the ancestry of the code?
>
> - What is the ancestry of your image?
>  (e.g. 11005, 11010, 11030)
>
> - What is the ancestry of the code you merge?
>  (e.g. 11005, 11010, XXXX)

lukas you can see the scenario I described using the 11a image up to  
11030 and select headingRemoval of Jannik.

> In the example above the common ancestory is 11010. So what Monticello
> does is to load the delta between 11010 and Janiks branch XXXX. If
> this does not touch any changes that have been made between 11010 and
> 11030 there is no conflict and that can be merged automatically.

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.


>> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Merging Algorithm Question

Lukas Renggli
> 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.

If you remove Presenter and Jannik does touch it, then you should get
a conflict.

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).

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
Reply | Threaded
Open this post in threaded view
|

Re: Merging Algorithm Question

Stéphane Ducasse

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
Reply | Threaded
Open this post in threaded view
|

Re: Merging Algorithm Question

Lukas Renggli
When I merge Morphic-jannik_laval.400 into the latest Pharo 1.1 I do
not get a class called Presenter.

Or what ***exactly*** did you try to do?

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
Reply | Threaded
Open this post in threaded view
|

Re: Merging Algorithm Question

Stéphane Ducasse

On Nov 7, 2009, at 8:45 AM, Lukas Renggli wrote:

> When I merge Morphic-jannik_laval.400 into the latest Pharo 1.1 I do
> not get a class called Presenter.
>
> Or what ***exactly*** did you try to do?

***Thanks*** for trying.

I  merged the slice and I was puzzled. I will redo today after fixing  
my house (as usual).

Stef



>
> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Merging Algorithm Question

Lukas Renggli
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

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Merging Algorithm Question

Stéphane Ducasse
ok thanks for checking.

> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project