Hi Marcus, Speaking of .changes and .source files, I remember a mid-term goal of introducing them inside the image. This would imply only one file (.image) and not so much space wasted IIRC an experiment (done by Camillo?) where it was zipped on the fly. Am just wondering if this is still a goal?
Luc 2015-03-10 7:58 GMT+01:00 Marcus Denker <marcus.den...@inria.fr>: > > > On 10 Mar 2015, at 07:36, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > > Laura, > > > > You can do that using the expression: > > > > PharoChangesCondenser condense > > > > Although that also means you lose the version history of methods inside > your image. This is typically not done a lot, maybe for production deploy, > maybe for release of Pharo itself. > > > > > Yes, but we need to change that. The artefact on the CI server needs to be > the artefact of release. We should not have *anything* of the kind “and a > day before release we call X”. > Because for sure it will be broken. And we waste resources: the changes > are the history of the revision control system. > > The current system has multiple problems: > > - Why have them *in addition* in a file on disk of everyone even though > almost nobody will ever look at them? > - We have to maintain two history mechanisms. Hard to explain: “Yes, > version of a method does not show you the version to committed when you use > a new image”. WTF? > - It does not scale. We clear the history between releases as the > .changes get too large. So the practical use of the history is not very high > - handling .sources, .changes and .sources is complex and hard to explain > - It is *SLOW*. Reading code from .sources/.changes is amazingly slow > - The code implementing all this is amazingly bad. Just look at the > references to SourceFiles: 44 references, all over the place. > > > Marcus >
