- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About MC

by Lukas Renggli

>> In either case there is never a hole. Each version stores the complete >> ancestry tree it knows, that is the filename and uuid of each version. >> The problem you run into is that you delete and move version files. If >> Monticello cannot find the files that it refers to in its ancestry you >> cannot merge automatically. That's why repositories should strictly be >> read-only. > > I do not really understand how we ended up with holes then. I guess I will have to explain it on a white-board, but here's another try: The problem is that Monticello cannot find the common ancestor because you deleted it from its repository. To fix the problem you have to find this version and tell Monticello where it can load it from by adding that repository. It is likely that you find the version somewhere on SqueakSource or in some package-cache on your machine. If you can't find the version you have to merge manually. This means you browse the other version or you calculate the changes between your version and the version you want to merge and apply the changes that you think should go in manually one-by-one. Then you 'adopt' that version to the ancestry. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by StÃ©phane Ducasse

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?

March 24, 2010

Re: [Pharo-project] About MC

by StÃ©phane Ducasse

>> during the integration I was thinking that we kept the complete ancestry. >> I thought that since we merge all the times, the ancestry is kept. >> My idea is that after just taking Pharo would be enough to merge. > > Can you elaborate? I don't understand the last sentence. I was thinking that the Pharo repository alone would be enough to make sure that we can always merge. > >> Now this is not the case: if I look at Polymorph-Widgets for example I have >> holes and this is probably due to a load versus a merge. > > There is not much of a difference between the two: > > - When loading the working copy has the loaded version as an single ancestor. > > - When merging the working copy has the previously loaded version and > the merged version as an ancestor. > > In either case there is never a hole. Each version stores the complete > ancestry tree it knows, that is the filename and uuid of each version. > The problem you run into is that you delete and move version files. If > Monticello cannot find the files that it refers to in its ancestry you > cannot merge automatically. That's why repositories should strictly be > read-only. I do not really understand how we ended up with holes then. Stef > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by Lukas Renggli

> 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

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 24, 2010

Re: [Pharo-project] ConfigurationOfDrGeo for Pharo

by Hilaire Fernandes

Absolutely, if nothing else is in my path, it is the next thing I want to do: using polymorph to provide a feature complete UI for DrGeo, I have been waiting for that since a long time. Hilaire Lukas Renggli a Ã©crit : > DrGeo is a really cool system. It is great to see it in action in Pharo. > > Are there any plan to integrate it into a window with menu and/or > toolbar? First I had some troubles to find out how it works :-) >

March 24, 2010

Re: [Pharo-project] About MC

by Lukas Renggli

> during the integration I was thinking that we kept the complete ancestry. > I thought that since we merge all the times, the ancestry is kept. > My idea is that after just taking Pharo would be enough to merge. Can you elaborate? I don't understand the last sentence. > Now this is not the case: if I look at Polymorph-Widgets for example I have > holes and this is probably due to a load versus a merge. There is not much of a difference between the two: - When loading the working copy has the loaded version as an single ancestor. - When merging the working copy has the previously loaded version and the merged version as an ancestor. In either case there is never a hole. Each version stores the complete ancestry tree it knows, that is the filename and uuid of each version. The problem you run into is that you delete and move version files. If Monticello cannot find the files that it refers to in its ancestry you cannot merge automatically. That's why repositories should strictly be read-only. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by Lukas Renggli

> 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

March 24, 2010

[Pharo-project] About MC

by stephane ducasse

during the integration I was thinking that we kept the complete ancestry. I thought that since we merge all the times, the ancestry is kept. My idea is that after just taking Pharo would be enough to merge. Now this is not the case: if I look at Polymorph-Widgets for example I have holes and this is probably due to a load versus a merge. Lukas may be you know more than me on the topic. What do you think? Stef

March 24, 2010

Re: [Pharo-project] ConfigurationOfDrGeo for Pharo

by Lukas Renggli

DrGeo is a really cool system. It is great to see it in action in Pharo. Are there any plan to integrate it into a window with menu and/or toolbar? First I had some troubles to find out how it works :-) Lukas On 24 March 2010 16:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > this is cool hilaire! > > Stef > > On Mar 24, 2010, at 3:29 PM, Hilaire Fernandes wrote: > >> Hello, >> >> I have updated DrGeo to make it compliant to Pharo 1.0 (hello Laurent). >> I took the opportunity to write a ConfigurationOfDrGeo using Metacello package management facility. >> >> The Configuration is for now in the DrGeo repository: http://squeaksource.com/DrGeoII/ >> >> in case someone want to test it. >> >> Hilaire >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

March 24, 2010