[Pharo-project] May be some problems with MC history
hi all yesterday I decided to have a look at MC changes in squeak to see if this has an impact for the closure last fixes merge. So I did with the latest scriptLoader in the pharo repository ScriptLoader new addExtraRepositories then I select each version of the monticello package in squeak trunk starting from 314 up to 321 and used the history and asked to get the delat with the previous version. This way I could get all the changes one by one. Now I ended up having - methods refering to instance variables that were not included (methodDefinitiosn for example with 321) - when I run the tests I realized that most of the Mock classes where gone. Except for 321 I do not see a change that could affect the MC merging. Does any (lukas) use the history feature to merge? I will retry to do the changes one by one and run the tests in between to see what went wrong but I 'm not sure that what is going wrong is the changes (I have the impression that may be MC history is not capturing exactly everything but I can be wrong). Stef
Does any (lukas) use the history feature to merge?
Sometimes, if I would like to merge changes made in another branch. Imagine the following situation: a.1 ---- wc (working copy) \---- b.1 --- b.2 Now I want to include the changes that happened between b.2 and b.3, but not those that were done between a.1 and b.1. I use the history and to calculate a diff between b.1 and b.2 and selectively load the changes. If the changes are separate from what happened between a.1 and wc and a.1 and b.1 this should be relatively simple. Unfortunately Monticello cannot figure out such dependencies, because it keeps the ancestry on a package level only. In fact, with Monticello 2 an operation like this should be smooth and automatic like a normal merge.
I will retry to do the changes one by one and run the tests in between to see what went wrong but I 'm not sure that what is going wrong is the changes (I have the impression that may be MC history is not capturing exactly everything but I can be wrong).
MC1 does not capture the ancestry of the individual methods, that's why you have to extremely careful and check if you do not override changes that were made between a.1 and wc and if you do not introduce changes made between a.1 and b.1. I know this can be very tricky, especially when there are many changes between a.1 and wc and a.1 and b.1. MC2 promises rescue here. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
thanks lukas in general you did not get any problems? Beause I was careful and the changes seemed simple except the last one The result is that apparently I lost classes that were not in the changes! and instance variables. I'm now comparing with the squeak trunk image to see if this is an MC problem because this is the first time I got that strange behavior. Stef On Sep 11, 2009, at 9:09 AM, Lukas Renggli wrote:
Does any (lukas) use the history feature to merge?
Sometimes, if I would like to merge changes made in another branch. Imagine the following situation:
a.1 ---- wc (working copy) \---- b.1 --- b.2
Now I want to include the changes that happened between b.2 and b.3, but not those that were done between a.1 and b.1. I use the history and to calculate a diff between b.1 and b.2 and selectively load the changes. If the changes are separate from what happened between a.1 and wc and a.1 and b.1 this should be relatively simple. Unfortunately Monticello cannot figure out such dependencies, because it keeps the ancestry on a package level only. In fact, with Monticello 2 an operation like this should be smooth and automatic like a normal merge.
I will retry to do the changes one by one and run the tests in between to see what went wrong but I 'm not sure that what is going wrong is the changes (I have the impression that may be MC history is not capturing exactly everything but I can be wrong).
MC1 does not capture the ancestry of the individual methods, that's why you have to extremely careful and check if you do not override changes that were made between a.1 and wc and if you do not introduce changes made between a.1 and b.1. I know this can be very tricky, especially when there are many changes between a.1 and wc and a.1 and b.1. MC2 promises rescue here.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
a couple of bugs when understanding the history based merge (ugly) - 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! This functionality by passes the changeset and this is not a good idea. Stef On Sep 11, 2009, at 11:56 AM, Stéphane Ducasse wrote:
thanks lukas
in general you did not get any problems? Beause I was careful and the changes seemed simple except the last one The result is that apparently I lost classes that were not in the changes! and instance variables.
I'm now comparing with the squeak trunk image to see if this is an MC problem because this is the first time I got that strange behavior.
Stef
On Sep 11, 2009, at 9:09 AM, Lukas Renggli wrote:
Does any (lukas) use the history feature to merge?
Sometimes, if I would like to merge changes made in another branch. Imagine the following situation:
a.1 ---- wc (working copy) \---- b.1 --- b.2
Now I want to include the changes that happened between b.2 and b.3, but not those that were done between a.1 and b.1. I use the history and to calculate a diff between b.1 and b.2 and selectively load the changes. If the changes are separate from what happened between a.1 and wc and a.1 and b.1 this should be relatively simple. Unfortunately Monticello cannot figure out such dependencies, because it keeps the ancestry on a package level only. In fact, with Monticello 2 an operation like this should be smooth and automatic like a normal merge.
I will retry to do the changes one by one and run the tests in between to see what went wrong but I 'm not sure that what is going wrong is the changes (I have the impression that may be MC history is not capturing exactly everything but I can be wrong).
MC1 does not capture the ancestry of the individual methods, that's why you have to extremely careful and check if you do not override changes that were made between a.1 and wc and if you do not introduce changes made between a.1 and b.1. I know this can be very tricky, especially when there are many changes between a.1 and wc and a.1 and b.1. MC2 promises rescue here.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
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.
Yes I know, I did not mean merging. Sorry for the bad working,
- 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?
there is a menu item: 'add to changeset' and I wanted to generate a cs for each of the commit because I wanted to be able to reload the work in another image to test. And not load and fuck up and restart kind of scenario.
Class definitions are part of the patch that is calculated by Monticello.
probably but when you use add to changesets they don't.
My guess is that the class didn't change for the delta you calculated.
Yes this is what I discovered see below. Now I really understand the limits of the functionality.
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.
I wanted to know if I can trust this functionality. So I did the following experiment and I learned a lot and now I deeply understanding what you mean :) I took latest pharo ScriptLoader new addExtraRepositories then you open the trunk repository and browse the monticello package I checked the changes made in ar 321, did not see an instance variable called methodAdditions nor the initialize method modification. The previous version of initialize was made in 2007. I compare the history between md.308 july 2006 and rkrk.320 there I saw that the initialize methods was added. I added the 3.10 repository and I found that the method initialize was added in rej.309 in 310. So now I understand and it would be nice to have a functionality to now when a change occurred. So now I can use the history and yes we should really be cautious. I wrote these emails so that other people can learn from it. So thanks lukas. Stef PS: L'idee de l'experience ne remplace pas l'experience So I'm happy I know more now :)
I don't understand what this has to do with change-sets?
there is a menu item: 'add to changeset' and I wanted to generate a cs for each of the commit because I wanted to be able to reload the work in another image to test.
Sorry, never used (or even encountered) that menu item before.
So thanks lukas.
No problem ;-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch
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... Dave
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...
Dave
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
David T. Lewis -
Lukas Renggli -
Stéphane Ducasse