[squeak-dev] Re: Magma back end to SqueakSource (was: Re: Build.squeak.org and squeaksource.com in danger (was Re: [Box-Admins] Disk space usage on box3))

Chris Muller asqueaker at gmail.com
Sun Dec 8 23:47:43 UTC 2013


Magma itself supports persisting change-sets via the following API:

==============
  "file-out a ChangeSet"
  mySession commit: [ mySession codeBase fileOutChangeSet:
(ChangeSorter changeSetNamed: 'myChangeSet') ]

  "Load a ChangeSet"
  mySession codeBase fileInChangeSetNamed: 'myChangeSet'

  "browse a change-set before filing it in"
  mySession codeBase browseChangeSetNamed: 'myChangeSet'

  "Answer a collectioon of all changeSet names in the codeBase."
  mySession codeBase changeSetNames

  "Install all the changeSets in the codeBase immediately."
  mySession codeBase installChangeSets
===============

But I didn't do anything to integrate methods stored in change-sets
this way into the new MC History function.

Seems like it would be a neat thing to do though if someone had the time..



On Sat, Dec 7, 2013 at 5:54 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sat, Dec 07, 2013 at 04:58:51PM -0600, Chris Muller wrote:
>>
>> I thought about it 4 years ago and made an object model to take care
>> of it.  The problem with zip-files is how wasteful they are.  When
>> someone changes one single method of the Morphic package, the other 1K
>> definitions (however many there are) are duplicated in new zip (mcz)
>> file.  By contrast, the object model refers to the same canonicalized
>> MCDefinition instances across Versions, adding only one new
>> MCDefinition to the bulk of the model in that example.
>>
>> The result is that the redundant Magma-backed copy of
>> source.squeak.org consumes less than 1/4th the space of the original
>> File based version.  A Magma-backed copy of squeaksource.com would
>> about 12GB of space.
>>
>> PS -- For interest, I just kicked off a bulk-load of entire
>> squeaksource.com repository into Magma to see how much space it will
>> take..
>>
>
> I changed the subject line, and am moving the discussion over to squeak-dev
> because I think it may be of more general interest.
>
> I'm quite interested to know how that turns out. Entirely aside from
> disk space concerns, the approach you are describing makes a lot of
> sense to me, and the squeaksource.com archive provides a fairly large
> data set to try it out.
>
> Bob Arning has been doing some really interesting things with a Seaside
> browser for exploring the change set records of earlier Squeak development.
> Meanwhile you (Chris) are doing equally interesting work to enable a
> Monticello browser to browse through the historical record of source.squeak.org,
> backed up a Magma-enabled image currently running on box4.squeak.org:8888.
>
> I have a of vague hand-waving notion that these two should be related, and
> that if I wanted to figure out how some method in e.g. ObjectMemory came
> into being, it would be really convenient if I could explore its change
> history to see various things that Eliot or Tim or I might have done in
> recent years in the Monticello repositories, and continue back in time
> through the change set update stream to see how and why Dan Ingalls might
> have originally implemented it in Squeak 1.x.
>
> Is there some way in which the change set based update stream from earlier
> Squeak could also be captured in the Magma back end, similar to what you
> are doing with the Monticello packages?
>
> Dave
>


More information about the Squeak-dev mailing list