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

Camillo Bruni camillobruni at gmail.com
Tue Mar 6 14:05:57 EST 2012


maybe you want to create a test git repos with all the sources back to 1.0 :D
and then we should record all changes into a local git-repos :)
if you want to got back some versions you simply start fetching the missing objects from a central repos somewhere...

so far dreaming a bit


On 2012-03-06, at 20:01, Marcus Denker wrote:

> On Mar 6, 2012, at 7:30 PM, Max Leske wrote:
>> This may be a stupid question… (As far as I understand, condensing the changes is not the same)
>> Why don't you increment the version number of the sources file to 1.1 and use a fresh changes file?
> The sources file does not contain the sources and the changes just the changes. (even though one could think so taking
> the names into account.)
> The sources file containes the sources of ages ago (1.0), the .changes is "on top of that". This means that the .sources
> file contains a lot of code from classes and methods that have been removed (like the changes),
> as well as old versions.  
> The .sources/.changes mechanism merges three responsabilties: 
> 1) be a log of all edited code in case of a crash
> 2) store the current source of the methods (when you ask a method for code, it reads either from the .sources
> (method not changed since 1.0) or from the .changes (method was changed). 
> 3) provide a history for all code
> 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.
> When you do a #condenseSources (which is sadly broken right now), then it generates a .sources
> file with just the code in the current image. It would be interesting to see how large that is.
> 	Marcus
> --
> Marcus Denker -- http://marcusdenker.de

More information about the Pharo-dev mailing list