On Tue, Feb 26, 2013 at 2:38 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 26 February 2013 19:13, Chris Muller <ma.chris.m at gmail.com> wrote:
>> What I did in my MaInstaller was to have a #merge: function which
>> would normally be used all the time (instead of #install:).  So
>> whichever one was more up-to-date would be loaded or, even if they
>> were branches of each other it would still work too as long as there
>> were no method-level conflicts.  (If there are method-level conflicts
>> then the interactive Merge dialog is presented where the user can make
>> a choice and proceed with the rest of the install by clicking Merge).
>>
>> If something isn't installed at yet, #merge: behaves exactly like #install:.
>
> OK, but that's not what I'm getting at. It's not actually a problem
> yet because this thing's not finished, but my point is that we'd have
> two things that lazily pulled in WebClient... and if SM simply had to
> use version N or later, and InstallerGitHub pulled in version N-1
> because you ran it before you opened the catalog, Bad Things might
> well happen. Especially so since "is WebClient installed?" is answered
> by Smalltalk at: #WebClient (really, this should be self class
> environment at: #WebClient). SM goes "oh cool, it's already loaded, so
> I'll just invoke this new behaviour OH NO MNU"

Hmm, so it seems to me the unconditional merge idea still solves all
cases including that one doesn't it?  If SM was second, it would merge
version N prior to its work.  If InstallerGitHub was second, its merge
of N-1 would have no effect since it was already in the ancestry..

In any case, as you said, this hardly seems like an issue because, if
it were, the energy to rectify it wouldn't be to make them operate on
different verisions but on the same, (most-recent) version.