[Pharo-project] .changes are now 37MB….

Eliot Miranda eliot.miranda at gmail.com
Wed Mar 7 12:31:10 EST 2012


On Wed, Mar 7, 2012 at 1:56 AM, Craig Latta <craig at netjam.org> wrote:

>
> > > > And all that in 2 big files that one can only append to because?
> > > > No idea, actually...
> > > >
> > > > I personally think that it is a mistake today to merge all these
> > > > into one such basic mechanism. Especialy if
> > > > you look at how complex the code is in the image... it's actually
> > > > amazing.
> > >
> > >     Hear hear. I think it's insane to do it (only) this way at this
> > > point. Objects everywhere...
> > >
> > can you elaborate? do what at which point?
>
>      To use source code written on files to record history information,
> at this point in history where we have more than enough processor,
> network, and disk to just use live distributed object memories. I can
> see keeping the old stuff around for a while as a redundancy mechanism,
> but we needn't rely on it alone.
>

But both Occam's razor and IIABDFI (if-it-aint-broke-dont-fix-it) say we
should keep with it.  It has worked extremely well with Squeak/Pharo, is
robust, persistent, and simple.  Realistically we're not going to move to
Spoon over night, so what to do about a 37Mb changes file is a pressing
issue.  Being able to compress with history and/or write a new sources file
with compressed history makes sense.  It's not being unimaginitive or
regressive, or anti-innovation; merely pragmatic.


>
> -C
>
> --
> Craig Latta
> www.netjam.org/resume
> +31 6 2757 7177
> + 1 415 287 3547
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120307/99b6418b/attachment-0001.html>


More information about the Pharo-dev mailing list