On Jan 15, 2010, at 9:50 PM, Levente Uzonyi wrote: > On Fri, 15 Jan 2010, Stéphane Ducasse wrote: > >> thanks levente. >> >> Now since this can also help squeak people. The trunk does not contain the >> complete history so this breaks monticello >> then browsing history. In pharo we pay attention to get **all** the ancestor >> chain for such a kind of analysis. > > I don't get you. The trunk allows you to rebuild an image from 3.10.2 to the > actual state, so it contains the complete history since 3.10.2.
There is a huge difference between been able to build an image as a list of changes apply to the previous snapshot from apply the last version of package to the original image. We learned that the hard way doing 3.9. Now this was not my point. My point is that MC like to have all the ancestors when we use merge in the history panel. if you click on File-ul.58.mcz then History you get the list with all the ancestors but some of them are not on the repository so you cannot view changes -> > IIRC this MC bug has been fixed in the trunk. ok what is the logic to find that File.31 was the ancestor of File.47? If this is the just to take the next matching number I prefer to get a pop up saying that 46 is not found. Because MC is a distributed version system so you should not take the hypothesis that all the versions are in the same repository. So I'm curious to know if we talk about the same. Stef > >> >> Stef >> >> On Jan 15, 2010, at 7:14 PM, Levente Uzonyi wrote: >> >>> On Fri, 15 Jan 2010, Mariano Martinez Peck wrote: >>> >>>> Hi: Today Stef and I have being harvested Squeak changes in FileStream. The >>>> most important is the work from Levente and the buffer. >>>> >>>> We commit the first slide in inbox: SLICE-FileStream-StephaneDucasse.1 >>>> >>>> Can someone take a look please because is this quite "important" to >>>> integrate. >>> >>> StandardFileStream >> #readInto:startingAt:count: is wrong, there's a >>> newer version. StandardFileStream >> #skip: is missing. >>> The changes for MultiByteFileStream are also missing. Without those, the >>> files' state may become corrupt and the expected system-wide speedup will >>> be less significant. >>> Changes of classes other than StandardFileStream are unrelated to the read >>> buffering in the slice. >>> >>> >>> Levente >>> >>>> >>>> Thanks >>>> >>>> Mariano >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
