2010/1/15 Stéphane Ducasse <[email protected]>: > > 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
I find MC a bit pedantic sometimes. I think this happens when we merged a private version somewhere on someone disk with a trunk version then published. MC keep track of the merged private version and insist on having this branch when we further merge in Pharo. FYI, exactly the same happened to me when I tried to merge some Pharo version in squeak (an obscure DamienCassou branch was missing in pharo repository, can't remember which package though...). Instead of complaining instructively, MC was sending snapshot to nil... I just let it ignore the problem. In Pharo, you choosed to signal the problem with an explicit message, maybe that help fixing wrong configurations, but sometimes you should just have the option to ignore and proceed. Nicolas >> >>> >>> 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
