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 >
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
