>>> >>>> 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. > > Indeed, noone wants the latter, because it limits the range of changes > available.
But I would pay to have that possibility (but it will not possible in Smalltalk since Smalltalk does not have a declarative model of execution). >> 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 -> >> > > This is the bug I was talking about. It's a bug, since viewing the changes is > indepentent of the ancestors. Ok then I will have a look. > >>> 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? > > MC shows you the ancestors of the currently loaded package (normal style, no > undelines, not bold). There's also the history button which shows all > ancestors with their commit messages, UUIDs, etc. > > > Levente > >> 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 > _______________________________________________ > 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
