OK, that actually got me a fair way. I still think we need an MCError,
but otherwise the change is to turn InstallerMonticello's mc into an
MCRepositoryGroup and make MCRepositoryGroup a bit more like an
MCRepository.

As a neat side effect, I don't need a separate #failover: -
InstallerMonticello automatically checks the cache first (this is
default MCRepositoryGroup behaviour), and you add failovers just by
adding more repositories:

Installer ss
    http: 'http://my.special.local.cache/';
    http: 'http://ss3.gemstone.com/ss/';
    project: 'Foo';
    install: 'Bar-fbs-22.mcz'

will try install Bar-fbs-22.mcz first from the cache, then from ss,
then from a local cache, and finally from ss3.

I need to roll out the change a bit further so all the other bits of
Installer work once more - #basicView:, #printOn: and so on - and then
should have something ready to be ripped apart by peer review.

frank

On 22 January 2013 00:51, Chris Muller <asqueaker at gmail.com> wrote:
> One design aspect of MC is that it supports many different "repository
> types".  So how about letting Installer install from a "composite"
> type -- in fact we already have MCRepositoryGroup which currently
> doesn't seem to have a lot of value -- so it could be an opportunity
> to make it more worth its weight without introducing any "new" API
> complexity.  The install script would just set up the
> MCRepositoryGroup instance with the repositories in the order they
> want and tell Installer to install normally using same existing API as
> the regular repository types (FileBased, etc.).
>
>
>
> On Mon, Jan 21, 2013 at 5:04 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> I have a change to InstallerMonticello that allows it to fail over to
>> an alternate repository. That means that
>>
>> Installer ss
>>     package: 'Zippers';
>>     install: 'Zippers-fbs.52.mcz'.
>>
>> will attempt to load the mcz from the local cache, but fall over to
>> the canonical repository. Alternatively, one could say
>>
>> Installer ss
>>     package: 'Zippers';
>>     failover: (Installer ss3 package: 'Zippers'; mc);
>>     install: 'Zippers-fbs.52.mcz'.
>>
>> which would try SqueakSource before falling back to ss3.gemstone.com.
>> (I currently don't support multiple failovers, but I should.)
>>
>> Now to my question: if you try load a file from an
>> MCFileBasedRepository that does not exist, you get a
>> FileNotFoundException. I think this should be caught, and an MCError
>> (which doesn't exist yet, but should) raised. My rationale is this:
>> driving Monticello from the outside (like Installer does), I don't
>> care about the precise kinds of errors that may occur.
>> FileNotFoundException, NameLookupFailure, whatever, I only care that
>> MC failed to do something.
>>
>> In particular, I DO NOT want to catch Error. And, I DO NOT want to
>> scatter every possible kind of exception that might occur because a
>> user decided to use a GOODS repository and I forgot to figure out what
>> kinds of exceptions that kind of repository might throw.
>>
>> Thoughts? Rethrow underlying exceptions as a generic-but-specific-to-MC MCError?
>>
>> frank
>>
>