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
[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
