2015-03-10 7:58 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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
And getting lower and lower with repositories where one can query for the history of a method, such as gitfiletree.
- 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.
And where it could be reused, such as for doIts, a new mechanism with on disk files is created to store source code: the GTPlayground cache :( But stiil, the changes allow you a recovery in case of a crash. It has some valuables side effects. Thierry