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_re... 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... 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