On 10 Mar 2015, at 07:36, Sven Van Caekenberghe <sven@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