[Pharo-dev] unexpected lack of Method Version History (due to CI process?)

Marcus Denker marcus.denker at inria.fr
Tue Oct 1 02:48:42 EDT 2013


On Oct 1, 2013, at 3:54 AM, btc at openinworld.com wrote:

> Marcus Denker wrote:
>> 
>> On Sep 30, 2013, at 5:40 PM, btc at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131001/41b62220/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131001/41b62220/attachment.asc>


More information about the Pharo-dev mailing list