On Mar 25, 2011, at 3:29 PM, Tudor Girba wrote:
> Sounds great. So, what needs to be done then?
That depends upon what you are trying to do...For GemStone I have a class
called GLASSProjectSupport that does the following:
1. fetches all mczs and configurations for ConfigurationOfGLASS into an
in-memory dictionary-based repository
2. copies new mcz files (packages and configs) into a directory in an svn
checkout directory, recording the original repository from which the
package
was downloaded
3. updates a packing list file so that the new mcz files are automatically
copied into
the correct directory for release
4. generates a topaz script that is used to bootstrap GLASS from the svn
directory
and the repository map is used to set the repositoryGroup correctly (as
if the mcz
files weren't loaded from the svn directory).
The basic script for doing step 1 is here:
http://code.google.com/p/metacello/wiki/FAQ#How_do_I_create_a_local_cache_repository_for_a_config?
although you would probably want to set ignoreImage: to true:
version ignoreImage: true.
There's a little bit more monkey business if you want to store your project
configuration (like ConfigurationOfGLASS) in your archive directory.
If you want to record the original repositories or get your hands on the list
of mcz files/configs that were loaded, then it gets a little more complicated:
loadDirective := version fetch loadDirective
You can traverse the loadDirective and extract the additional information you
might want ...
If you are going to load using Metacello then a script for step 4 is here:
http://code.google.com/p/metacello/wiki/FAQ#How_do_I_override_the_repository_for_a_config?
I have toyed with the idea of creating something like a .mar file which would
essentially encapsulate the above into a couple of steps:
- one for create the .mar file
- one for loading from the .mar file
The .mar file would be a zipped up directory repository plus some sort of doit
that would provide the load instructions/options....for a .mar file it might be
worth restoring the repositoryGroups for the mcz files, which means recording a
repository map...
I haven't looked closely at the .sar file stuff, but maybe the .mar file could
be wrapped in a .sar so that other deliverables could be included ... and a
.mar file would just be a special case of a .sar file?
I am partial to the .mar file idea and I don't think there's that much new that
would have to be invented, but I haven't thought through all of the issues yet
... but now might be a good time to encapsulate the whole process and tie it up
with a bow:)
Dale
