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
|