> 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