> On 10 Mar 2015, at 07:36, Sven Van Caekenberghe <[email protected]> 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
