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
>
> 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
> [hidden email]
> 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.
>
> 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

> 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" <[hidden email]> 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
> | [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

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