> On 13 Mar 2015, at 09:18, stepharo <steph...@free.fr> wrote:
>
>
>>>>>
>>>>> 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.
>>>
>>> OK so a silly and not-so-innocent question: Why not include that in the
>>> build script *right now* ? It has to be done some time, and now the
>>> discussion is open why not make use of the opportunity?
>>>
>>> Also, my use of the changes file is uniquely to recover in case of a crash.
>>> With condensed changes for every daily build I download this would make my
>>> recovery just that bit easier. One small change …
>>>
>>
>> From a size point of view it would make sense: a “Pharo4.sources” is even a
>> bit smaller than the current .changes (which itself would be empty).
>> Compressed it would be 15,7 instead of 13,7 due to the .changes
>> being better compressible (it contains much useless things even by that
>> metric…)
>>
>> The problem is that we would need to see how it plays with the get.pharo.org
>> <http://get.pharo.org/> where the vm download contains all of Pharo1, Pharo2
>> and Pharo3 sources…
>
> I do not understand your stress. If we produce a condense change files what
> is the problem.
> You are talking about the problem of having multiple .sources?
yes. we download always *all* sources files with the VM.
Marcus
