Binaries in Monticello

Avi Bryant avi at beta4.com
Fri Feb 13 19:42:31 UTC 2004


On Feb 13, 2004, at 9:45 AM, Julian Fitzell wrote:

> Bert Freudenberg wrote:
>>>
>> I'd like a way to check binary files from disk into a MC repository 
>> (similar to CVS). Alternatively, or perhaps additionally, a way to 
>> store an image segment with the code.
>
> We talked about being able to do that early in the MC development 
> cycle and I'm pretty sure it should still be doable.  Andrew and I 
> have a need for this at work so we'll probably do it eventually if 
> nobody else does, but it won't be until the end of march, I'd guess...

A couple of pointers to anyone that wants to look at implementing this:
- what gets stored in a package version is defined by 
MCPackage>>snapshot.  Right now all this does is build ClassDefinitions 
and MethodDefinitions from the associated PackageInfo, but there's no 
reason it couldn't throw other kinds of definition objects in there as 
well (MCImageSegmentDefinition?).  There just has to be some kind of 
registry so it knows how to create the right image segments for each 
package.
- The most important things for a new subclass of MCDefinition to 
implement are #description and #=.  #description must return some 
unique id for the definition that will not change even if its contents 
do - so, for example,

MCMethodDefinition>>description
	^ Array	
		with: className
		with: selector
		with: classIsMeta

For an image segment you might use the project name or something like 
that?  #=, of course, should detect if the actual contents have changed 
or not (so for a method definition it compares source, category, etc).  
#description and #= are together used to detect when you have a new 
version of the same definition, etc.
They should also implement #load, which needs to replace any old 
versions with the new one, and #summary, #source, and #sortKey for the 
browser views.  There's a dependency system (#provisions and 
#requirements) but I wouldn't expect binary data to need it.
- When MCMczReader is loading a file, it will look for an appropiate 
subclass of MCSnapshotReader for every file in the snapshot/ directory 
in the zip.  Right now there is always only source.st, and this is 
handled by MCStReader (due to MCStReader class>>extension ^ 'st').  The 
definitions produced from each of these files are combined to form the 
final snapshot.
- The hooks for writing aren't as good.  Right now it assumes a single 
snapshot writer class (ie, MCStWriter) can file out the whole snapshot. 
  Definitions would need to be sorted by writer class first, or 
something along those lines, in MCMczWriter>>visitSnapshot:.




More information about the Squeak-dev mailing list