unexpected lack of Method Version History (due to CI process?)
In the process of reviewing a fix to an issue [1] that I reported with PharoLauncher, I downloaded the latest CI result and browsed to the method I knew had changed [2]. I wanted to directly observe the change in the version history, but was surprised that there was no version history for the method. My uninformed intuition is this relates to some 'clean up for release' run as part of the build process to strip out old versions to compact the image delivered by the CI process, but does it make sense to do this for every build? I can understand not wanting this to grow indefinitely to bloat the image - but perhaps this compaction would be better only for major releases? I guess the downside is that you are then not exercising the 'full release' process every build. However having in image Version History extending a fair way back in time has always seemed to me to be one of the very cool (i.e. useful features of Pharo/Smalltalk). Without this, it feels like 'something' has been lost. The ultimate solution would seem to be linking the method version history to a network resource for the full history only as required per method. Any chance anyone is working on something like that? cheers -ben [1] https://pharo.fogbugz.com/f/cases/11614 [2] PharoLauncher>>createImageFromTemplate
On Sep 30, 2013, at 5:40 PM, btc@openinworld.com wrote:
In the process of reviewing a fix to an issue [1] that I reported with PharoLauncher, I downloaded the latest CI result and browsed to the method I knew had changed [2]. I wanted to directly observe the change in the version history, but was surprised that there was no version history for the method. My uninformed intuition is this relates to some 'clean up for release' run as part of the build process to strip out old versions to compact the image delivered by the CI process, but does it make sense to do this for every build? I can understand not wanting this to grow indefinitely to bloat the image - but perhaps this compaction would be better only for major releases? I guess the downside is that you are then not exercising the 'full release' process every build. However having in image Version History extending a fair way back in time has always seemed to me to be one of the very cool (i.e. useful features of Pharo/Smalltalk). Without this, it feels like 'something' has been lost. The ultimate solution would seem to be linking the method version history to a network resource for the full history only as required per method. Any chance anyone is working on something like that?
Keep in mind that the .changes history and monticello are completely separate. When you load a mc version, you just load *that version*. We really need to have the "versions" of the method go and ask the repo. Now the problem is that Monticello is not really nice: it has complete snapshots per commit in a zip file. Getting version out there of a method is not possible⦠without building infrastructure for it. Marcus
On Oct 1, 2013, at 3:54 AM, btc@openinworld.com wrote:
Marcus Denker wrote:
On Sep 30, 2013, at 5:40 PM, btc@openinworld.com wrote:
In the process of reviewing a fix to an issue [1] that I reported with PharoLauncher, I downloaded the latest CI result and browsed to the method I knew had changed [2]. I wanted to directly observe the change in the version history, but was surprised that there was no version history for the method. My uninformed intuition is this relates to some 'clean up for release' run as part of the build process to strip out old versions to compact the image delivered by the CI process, but does it make sense to do this for every build? I can understand not wanting this to grow indefinitely to bloat the image - but perhaps this compaction would be better only for major releases? I guess the downside is that you are then not exercising the 'full release' process every build. However having in image Version History extending a fair way back in time has always seemed to me to be one of the very cool (i.e. useful features of Pharo/Smalltalk). Without this, it feels like 'something' has been lost. The ultimate solution would seem to be linking the method version history to a network resource for the full history only as required per method. Any chance anyone is working on something like that?
Keep in mind that the .changes history and monticello are completely separate. When you load a mc version, you just load *that version*.
Thanks Marcus. I guess I have got too used working continuously in the one image and had not explicitly considered that. So obviously this will be the case for all packages that build on top of the Pharo-CI builds.
yes
However my understanding is the Pharo mainline CI is currently a continous load of sequential slices (until its CI build is fully bootstrapped). yes
So each load of a slice would grow the version history - and I guess that might be compacted when 3.0 is released. (??) .
yes, because the .changes is already very large again. (ceterum censeo: we need to get rid of .changes and .sources!)
S o what I'm wondering is if the 3.0 summer/winter maintenance releases shouldn't do the same compaction to discard the version history. Or is this how it works already?
Yes, we kill it shortly before the release.
We really need to have the "versions" of the method go and ask the repo. Now the problem is that Monticello is not really nice: it has complete snapshots per commit in a zip file. Getting version out there of a method is not possible⦠without building infrastructure for it.
Marcus
If no one gets to it earlier, that might make a nice GSoC project for next year.
yes. Marcus
Le 30/09/2013 17:51, Marcus Denker a écrit :
On Sep 30, 2013, at 5:40 PM, btc@openinworld.com wrote:
In the process of reviewing a fix to an issue [1] that I reported with PharoLauncher, I downloaded the latest CI result and browsed to the method I knew had changed [2]. I wanted to directly observe the change in the version history, but was surprised that there was no version history for the method. My uninformed intuition is this relates to some 'clean up for release' run as part of the build process to strip out old versions to compact the image delivered by the CI process, but does it make sense to do this for every build? I can understand not wanting this to grow indefinitely to bloat the image - but perhaps this compaction would be better only for major releases? I guess the downside is that you are then not exercising the 'full release' process every build. However having in image Version History extending a fair way back in time has always seemed to me to be one of the very cool (i.e. useful features of Pharo/Smalltalk). Without this, it feels like 'something' has been lost. The ultimate solution would seem to be linking the method version history to a network resource for the full history only as required per method. Any chance anyone is working on something like that?
Keep in mind that the .changes history and monticello are completely separate. When you load a mc version, you just load *that version*.
We really need to have the "versions" of the method go and ask the repo. Now the problem is that Monticello is not really nice: it has complete snapshots per commit in a zip file. Getting version out there of a method is not possible⦠without building infrastructure for it.
gitfiletree repositories have that capability, i.e. querying the repo to get all versions of a method (but I didn't write the code which merges both the changes history and the package repo history in the same version browser). Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (3)
-
btc＠openinworld.com -
Goubier Thierry -
Marcus Denker