[Pharo-project] funny behavior with MC
this is strange before lunch I could select Polymorph-Widgets and merge at will and now I cannot anymore because I got a message could not find versions for example 107 Now this is really strange because this is the first version that was merged so normally it should be found. It is either in the UIEnhancements repository or the one of pharo. Does anybody encountered this behavior? Right now I'm blocked. MC looks so mysterious we will have to fix it in the future. Stef
this is strange before lunch I could select Polymorph-Widgets and merge at will and now I cannot anymore because I got a message could not find versions for example 107
This problem is to be expected when you move or delete versions. You see this message when the closest ancestor of the version you have in your image and the one you merge cannot be found. It could help to add the TreatedInbox to the list of repositories. If you can't find the common ancestor you cannot automatically merge. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
what is strange is that when I merge the latest loaded version I got the normal "no changes" and I could merge without having to add a new repository. I think that in squeak they cut the problem (if you do not have the history what do you do). You should still be able to merge. Setf On Mar 24, 2010, at 6:02 PM, Lukas Renggli wrote:
this is strange before lunch I could select Polymorph-Widgets and merge at will and now I cannot anymore because I got a message could not find versions for example 107
This problem is to be expected when you move or delete versions.
You see this message when the closest ancestor of the version you have in your image and the one you merge cannot be found.
It could help to add the TreatedInbox to the list of repositories. If you can't find the common ancestor you cannot automatically merge.
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
what is strange is that when I merge the latest loaded version I got the normal "no changes" and I could merge without having to add a new repository.
Sure, because in this situation the common ancestor is the version you load (so it can always be found). And the delta between the working copy and the version you merge is empty, so you have no changes.
I think that in squeak they cut the problem (if you do not have the history what do you do). You should still be able to merge.
I don't think they do anything different? If the ancestor version is missing you simply cannot do a meaningful merge. It is as simple as that. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mar 24, 2010, at 6:46 PM, Lukas Renggli wrote:
what is strange is that when I merge the latest loaded version I got the normal "no changes" and I could merge without having to add a new repository.
Sure, because in this situation the common ancestor is the version you load (so it can always be found). And the delta between the working copy and the version you merge is empty, so you have no changes.
You did not get me right scenario 1: I click on the slice press merge get an error ancestor not found scenario 2: I click on the **latest working copy version* that led to the error of scenario and do merge I get no changes of course + scenario 1 and it merges without the error of scenario 1 (it means that he suddenly magically found the ancestry) for me there is a bug. Because between scenario 1 and 2 there is no difference since this is exactly the same version that I have as working copy.
I think that in squeak they cut the problem (if you do not have the history what do you do). You should still be able to merge.
I don't think they do anything different? If the ancestor version is missing you simply cannot do a meaningful merge. It is as simple as that.
Yes i see what you mean. You cannot use the ancestry to do a clever merge. What I meant is that we should be able to see what changed based on the latest loaded version (no need to have the complete ancestor since it is broken). Because often using the latest working copy and having the diff is only what I need. Is whatI'm sayign make sense?
what is strange is that when I merge the latest loaded version I got the normal "no changes" and I could merge without having to add a new repository.
Sure, because in this situation the common ancestor is the version you load (so it can always be found). And the delta between the working copy and the version you merge is empty, so you have no changes.
You did not get me right
    scenario 1: I click on the slice press merge get an error ancestor not found     scenario 2: I click on the **latest working copy version* that led to the error of scenario and do merge I get no changes of course
I do not understand. - What is the "latest working copy version"? The working copy is the code you currently have in your image. - What do slices have to do with this? They shouldn't, because in the end the dependent versions are merged individually.
    + scenario 1 and it merges without the error of scenario 1 (it means that he suddenly magically found the ancestry)
The ancestry cannot be lost. The .mcz files are the one thing that can disappear.
for me there is a bug. Because between scenario 1 and 2 there is no difference since this is exactly the same version that I have as working copy.
The working copy is just one of the variable things in the merge. There is also the other version you load (and that might be different in your scenarios), and the common ancestor between the two (again that might be different in your scenarios).
Yes i see what you mean. You cannot use the ancestry to do a clever merge. Â What I meant is that we should be able to see what changed based on the latest loaded version (no need to have the complete ancestor since it is broken).
The ancestry is not broken! The problem is that you miss *ancestor versions*, because they were deleted or moved.
Because often using the latest working copy and having the diff is only what I need. Is whatI'm sayign make sense?
To get a diff between your working copy and a version you select this version and click on changes. That doesn't require any other version but the selected one. It doesn't even use the ancestry information. No, I can't make sense of it :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch
The ancestry cannot be lost. The .mcz files are the one thing that can disappear.
Yes I know but the result is the same.
The working copy is just one of the variable things in the merge. There is also the other version you load (and that might be different in your scenarios), and the common ancestor between the two (again that might be different in your scenarios).
I know.
Yes i see what you mean. You cannot use the ancestry to do a clever merge. What I meant is that we should be able to see what changed based on the latest loaded version (no need to have the complete ancestor since it is broken).
The ancestry is not broken! The problem is that you miss *ancestor versions*, because they were deleted or moved.
I know now since we systematically merge during our process I wonder how we break it. May be this is when you publish the smalltalk rewrite. Could check if you have Polymorph-Widgets-lr.214 in your local cache? I know now let me repeat the bug I see scenario1 working copy polymorphWiget.7.mcz I click on polymorphWiget.24.mcz merge -> I get an error ancestor cannot be found scenario1 working copy polymorphWiget.7.mcz I click on polymorphWiget.7.mcz merge -> no changes (ok this is what I hope what arriving) Then I click on polymorphWiget.24.mcz merge -> I get no error. So for me there is something strange. Stef
The ancestry is not broken! The problem is that you miss *ancestor versions*, because they were deleted or moved.
I know now since we systematically merge during our process I wonder how we break it. May be this is when you publish the smalltalk rewrite. Could check if you have     Polymorph-Widgets-lr.214 in your local cache?
Yes, and it is also in <http://www.squeaksource.com/PharoTreatedInbox>. So you need to add that repository to be able to merge.
I know now let me repeat the bug I see
This is not a bug of Monticello. This is because you move versions around and you don't tell Monticello where to find them. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I know now let me repeat the bug I see
This is not a bug of Monticello.
It is or may be of the network because tell me the difference between scenario 1 and scenario 2? I think that you do not read what I'm writing. There is no difference except that in the first scenario it barks and the second it works. And I just merge the latest working copy (which means that I did nothing) in between. scenario1 working copy polymorphWiget.7.mcz I click on polymorphWiget.24.mcz merge -> I get an error ancestor cannot be found scenario1 working copy polymorphWiget.7.mcz I click on polymorphWiget.7.mcz merge -> no changes (ok this is what I hope what arriving) Then I click on polymorphWiget.24.mcz merge -> I get no error.!!!! AND I CAN MERGE!!!! None. So may be the network was flaky and when I merged the second time the package was loaded in my cache. I try to understand what is the problem.
This is because you move versions around and you don't tell Monticello where to find them.
But our process does not move them around since packages in the inbox are systematically merged and the merged versions are copied into pharo. Then the commited versions are moved to treated. So we have a merge barrier! to keep the ancestry. So by process we should not get that. This is strange that only this one is a problem (may be they are some others) but really few compared to the large number of package versions we have. So this is probably a glitch somewhere Lukas: I ***KNOW*** how MC branching/merging works. I KNOW IT. Now I'm trying to understand how the moved package could be moved in treated while it should have been to pharo.
So this is probably a glitch somewhere
I doubt so.
Lukas: I ***KNOW*** how MC branching/merging works. I KNOW IT. Now I'm trying to understand how the moved package could be moved in treated while it should have been to pharo.
I imagine that when you browsed the different repositories you touched the version and Monticello copied it to its cache. So it isn't enough to know how merging exactly works, but you need to know all the exact semantics of each mouse movement in the MC UI :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mar 24, 2010, at 10:50 PM, Lukas Renggli wrote:
So this is probably a glitch somewhere
I doubt so.
Lukas: I ***KNOW*** how MC branching/merging works. I KNOW IT. Now I'm trying to understand how the moved package could be moved in treated while it should have been to pharo.
I imagine that when you browsed the different repositories you touched the version and Monticello copied it to its cache. So it isn't enough to know how merging exactly works, but you need to know all the exact semantics of each mouse movement in the MC UI :-)
no this has nothing to do with me idiot you moved the package in the wrong repository I trying to understand why one scenario 1 it barks and on scenario 2 it works because this represents a lot of time wasted... And also what is the step in our process that created the hole in the ancestry. Stef
Stef and Lukas, The other situation that I have seen these types of errors is when the package that I am merging into(?) does not have the repository where the common ancestor mcz file is located. For example if I have Seaside.gemstone-dkh.500 with http://seaside.gemstone.com/ss/seaside in it's repository group. When I attempt to merge Seaside.lr.505 in http://www.squeaksource.com/seaside I get an error. If I add http://www.squeaksource.com/seaside to the repository group for Seaside.gemstone-dkh.500 and then try the merge, it works.. Does this help or have I missed something along the way:) Dale ----- "Stéphane Ducasse" <stephane.ducasse@inria.fr> wrote: | On Mar 24, 2010, at 6:46 PM, Lukas Renggli wrote: | | >> what is strange is that when I merge the latest loaded version I | got the normal "no changes" | >> and I could merge without having to add a new repository. | > | > Sure, because in this situation the common ancestor is the version | you | > load (so it can always be found). And the delta between the working | > copy and the version you merge is empty, so you have no changes. | | You did not get me right | | scenario 1: I click on the slice press merge get an error ancestor | not found | scenario 2: I click on the **latest working copy version* that led to | the error of scenario and do merge I get no changes of course | + scenario 1 and it merges without the error of scenario 1 (it means | that he suddenly magically found the ancestry) | | for me there is a bug. Because between scenario 1 and 2 there is no | difference since this is exactly the same version that I have | as working copy. | | > | >> I think that in squeak they cut the problem (if you do not have the | history what do you do). | >> You should still be able to merge. | > | > I don't think they do anything different? If the ancestor version | is | > missing you simply cannot do a meaningful merge. It is as simple as | > that. | | Yes i see what you mean. You cannot use the ancestry to do a clever | merge. What I meant is that we should be able to see what changed | based on the latest loaded version (no need to have the complete | ancestor since it is broken). | | Because often using the latest working copy and having the diff is | only what I need. Is whatI'm sayign make sense? | | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is normal because ancestry cross over repository. I think that there is something really strange. EIther you get a truly distributed system or you get a local. With MC you get a distributed which can be brittle (even if I understand well the problem ancestry is solving). I think that a pessimistic merge (more than just going one by one on the changes would help). Stef On Mar 24, 2010, at 8:12 PM, Dale Henrichs wrote:
Stef and Lukas,
The other situation that I have seen these types of errors is when the package that I am merging into(?) does not have the repository where the common ancestor mcz file is located.
For example if I have Seaside.gemstone-dkh.500 with http://seaside.gemstone.com/ss/seaside in it's repository group. When I attempt to merge Seaside.lr.505 in http://www.squeaksource.com/seaside I get an error.
If I add http://www.squeaksource.com/seaside to the repository group for Seaside.gemstone-dkh.500 and then try the merge, it works..
Does this help or have I missed something along the way:)
Dale ----- "Stéphane Ducasse" <stephane.ducasse@inria.fr> wrote:
| On Mar 24, 2010, at 6:46 PM, Lukas Renggli wrote: | | >> what is strange is that when I merge the latest loaded version I | got the normal "no changes" | >> and I could merge without having to add a new repository. | > | > Sure, because in this situation the common ancestor is the version | you | > load (so it can always be found). And the delta between the working | > copy and the version you merge is empty, so you have no changes. | | You did not get me right | | scenario 1: I click on the slice press merge get an error ancestor | not found | scenario 2: I click on the **latest working copy version* that led to | the error of scenario and do merge I get no changes of course | + scenario 1 and it merges without the error of scenario 1 (it means | that he suddenly magically found the ancestry) | | for me there is a bug. Because between scenario 1 and 2 there is no | difference since this is exactly the same version that I have | as working copy. | | > | >> I think that in squeak they cut the problem (if you do not have the | history what do you do). | >> You should still be able to merge. | > | > I don't think they do anything different? If the ancestor version | is | > missing you simply cannot do a meaningful merge. It is as simple as | > that. | | Yes i see what you mean. You cannot use the ancestry to do a clever | merge. What I meant is that we should be able to see what changed | based on the latest loaded version (no need to have the complete | ancestor since it is broken). | | Because often using the latest working copy and having the diff is | only what I need. Is whatI'm sayign make sense? | | | _______________________________________________ | 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
participants (3)
-
Dale Henrichs -
Lukas Renggli -
Stéphane Ducasse