On Fri, 15 Jan 2010, Stéphane Ducasse wrote:
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.
Indeed, noone wants the latter, because it limits the range of changes available.
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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project